* [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide
@ 2015-07-21 15:01 dsmith at redhat dot com
2015-07-21 18:01 ` [Bug translator/18701] " jistone at redhat dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: dsmith at redhat dot com @ 2015-07-21 15:01 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=18701
Bug ID: 18701
Summary: systemtap can't find $return for sys_fadvise64_64 on
rawhide
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: dsmith at redhat dot com
CC: mjw at redhat dot com
Target Milestone: ---
On rawhide (4.2.0-0.rc2.git2.1.fc24.x86_64), the syscall testsuite fails
because the syscall tapset has an error in it. The error boils down to not
being able to find $return in kernel.function("sys_fadvise64_64").return:
====
# stap -ve 'probe kernel.function("sys_fadvise64_64").return { print($return)
}'
Pass 1: parsed user script and 109 library script(s) using
243680virt/44816res/7728shr/36980data kb, in 190usr/50sys/239real ms.
semantic error: unresolved target-symbol expression: identifier '$return' at
<input>:1:58
source: probe kernel.function("sys_fadvise64_64").return {
print($return) }
^
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 285420virt/87524res/8712shr/78720data kb, in 1380usr/120sys/1505real ms.
Pass 2: analysis failed. [man error::pass2]
====
Here's the output of "eu-readelf -N --debug-dump=info
/usr/lib/debug/lib/modules/4.2.0-0.rc2.git2.1.fc24.x86_64/vmlinux" that
references "sys_fadvise64_64":
====
[a4fac8] subprogram
external (flag_present) Yes
declaration (flag_present) Yes
linkage_name (strp) "sys_fadvise64_64"
name (strp) "sys_fadvise64_64"
decl_file (data1) 158
decl_line (data2) 461
====
There didn't seem to be any "formal parameter" entries for sys_fadvise64_64.
I did find one reference to [a4fac8]:
====
[a4f2d3] GNU_call_site
low_pc (addr) 0xffffffff810910f6
abstract_origin (ref4) [a4fac8]
[a4f2e0] GNU_call_site_parameter
location (exprloc)
[ 0] reg5
GNU_call_site_value (exprloc)
[ 0] GNU_entry_value:
[ 0] reg5
[a4f2e7] GNU_call_site_parameter
location (exprloc)
[ 0] reg2
GNU_call_site_value (exprloc)
[ 0] GNU_entry_value:
[ 0] reg9
====
Note that this has been going on for several rawhide kernels. Also note that
the nd_syscall (non-dwarf) testsuite passes fine.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
2015-07-21 15:01 [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide dsmith at redhat dot com
@ 2015-07-21 18:01 ` jistone at redhat dot com
2015-07-21 20:06 ` jistone at redhat dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jistone at redhat dot com @ 2015-07-21 18:01 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=18701
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jistone at redhat dot com
--- Comment #1 from Josh Stone <jistone at redhat dot com> ---
I see similar results on kernel-4.0.7-300.fc22.x86_64. It looks like debuginfo
is forgetting to output a proper subprogram for SyS_fadvise64_64. We end up
getting this particular .return probe from the symbol table, which has no $vars
or $return.
First, recall that syscall wrappers give us sys_foo as an alias for SyS_foo,
which has all arguments as long, and then SYSC_foo is an inline with proper
argument types.
In my kernel debuginfo, I see just one subprogram "sys_fadvise64_64", with two
call site reference, similar to yours. Those call sites are in
"sys32_fadvise64_64" and "sys32_fadvise64, and all of these DIEs are in the CU
for "arch/x86/ia32/sys_ia32.c".
[9952c2] subprogram
external (flag_present) Yes
name (strp) "sys32_fadvise64_64"
decl_file (data1) 1
decl_line (data1) 195
prototyped (flag_present) Yes
type (ref4) [987da5]
low_pc (addr) 0xffffffff81090560
high_pc (data8) 40 (0xffffffff81090588)
frame_base (exprloc)
[ 0] call_frame_cfa
GNU_all_call_sites (flag_present) Yes
sibling (ref4) [995359]
[...]
[99533c] GNU_call_site
low_pc (addr) 0xffffffff81090586
abstract_origin (ref4) [995c28]
[...]
[995556] subprogram
external (flag_present) Yes
name (strp) "sys32_fadvise64"
decl_file (data1) 1
decl_line (data1) 232
prototyped (flag_present) Yes
type (ref4) [987da5]
low_pc (addr) 0xffffffff81090650
high_pc (data8) 33 (0xffffffff81090671)
frame_base (exprloc)
[ 0] call_frame_cfa
GNU_all_call_sites (flag_present) Yes
sibling (ref4) [9955e5]
[...]
[9955c1] GNU_call_site
low_pc (addr) 0xffffffff8109066f
abstract_origin (ref4) [995c28]
[...]
[995c28] subprogram
external (flag_present) Yes
declaration (flag_present) Yes
linkage_name (strp) "sys_fadvise64_64"
name (strp) "sys_fadvise64_64"
decl_file (data1) 160
decl_line (data2) 461
Then in the CU for "mm/fadvise.c", there's the real meat. There are four
relevant subprogram DIEs (with formal_parameters I'm skipping here):
[1864fa0] subprogram
external (flag_present) Yes
name (strp) "SyS_fadvise64_64"
decl_file (data1) 1
decl_line (data1) 28
prototyped (flag_present) Yes
type (ref4) [1857399]
inline (data1) inlined (1)
sibling (ref4) [1864fe7]
[...]
[1864fe7] subprogram
name (strp) "SYSC_fadvise64"
decl_file (data1) 1
decl_line (data1) 157
prototyped (flag_present) Yes
type (ref4) [1857399]
inline (data1) declared_inlined (3)
sibling (ref4) [1865023]
[...]
[1865023] subprogram
name (strp) "SYSC_fadvise64_64"
decl_file (data1) 1
decl_line (data1) 28
prototyped (flag_present) Yes
type (ref4) [1857399]
inline (data1) declared_inlined (3)
sibling (ref4) [18650d4]
[...]
[18650d4] subprogram
external (flag_present) Yes
name (strp) "SyS_fadvise64"
decl_file (data1) 1
decl_line (data1) 157
prototyped (flag_present) Yes
type (ref4) [1857399]
inline (data1) inlined (1)
sibling (ref4) [186511b]
These subprogram DIEs are only referenced in a single call chain:
SyS_fadvise64 -> SYSC_fadvise64 -> SyS_fadvise64_64 -> SYSC_fadvise64_64
[186511b] subprogram
abstract_origin (ref4) [18650d4]
low_pc (addr) 0xffffffff811e3940
high_pc (data8) 617 (0xffffffff811e3ba9)
frame_base (exprloc)
[ 0] call_frame_cfa
GNU_all_call_sites (flag_present) Yes
sibling (ref4) [18655b8]
[...]
[186515f] inlined_subroutine
abstract_origin (ref4) [1864fe7]
entry_pc (addr) 0xffffffff811e395f
ranges (sec_offset) range list [ e26a0]
call_file (data1) 1
call_line (data1) 157
[...]
[1865196] inlined_subroutine
abstract_origin (ref4) [1864fa0]
entry_pc (addr) 0xffffffff811e395f
ranges (sec_offset) range list [ e26a0]
call_file (data1) 1
call_line (data1) 159
[...]
[18651d7] inlined_subroutine
abstract_origin (ref4) [1865023]
entry_pc (addr) 0xffffffff811e395f
ranges (sec_offset) range list [ e26a0]
call_file (data1) 1
call_line (data1) 28
This is correct, but it seems like there should *also* be a concrete subprogram
with origin [1864fa0] for "SyS_fadvise64_64".
You can also see this in detailed stap results:
$ stap -l 'kernel.function("*fadvise64*")' -vv |& grep pc=
probe sys32_fadvise64@arch/x86/ia32/sys_ia32.c:232 kernel reloc=.dynamic
pc=0xffffffff81090650
probe sys32_fadvise64_64@arch/x86/ia32/sys_ia32.c:195 kernel reloc=.dynamic
pc=0xffffffff81090560
probe SyS_fadvise64@mm/fadvise.c:157 kernel reloc=.dynamic
pc=0xffffffff811e3940
probe SYSC_fadvise64_64@mm/fadvise.c:28 kernel reloc=.dynamic
pc=0xffffffff811e395f
probe SyS_fadvise64_64@mm/fadvise.c:28 kernel reloc=.dynamic
pc=0xffffffff811e395f
probe SYSC_fadvise64@mm/fadvise.c:157 kernel reloc=.dynamic
pc=0xffffffff811e395f
probe sys_fadvise64_64@:-1 kernel reloc=.dynamic pc=0xffffffff811e36d0
There's the real SyS_fadvise64 at e3940, with its three inlined functions all
at e395f. Then we do get sys_fadvise64_64 on its own at e36d0, but this came
from the symbol table, not debuginfo.
Note also that x86_64 doesn't have fadvise64_64 as its own syscall:
$ ausyscall --dump x86_64 | grep fadvise64
221 fadvise64
$ ausyscall --dump i686 | grep fadvise64
250 fadvise64
272 fadvise64_64
So the only non-inline reference to SyS_fadvise64_64 will be from the sys32
wrappers, which call it under the alias sys_fadvise64_64. Perhaps this is
confusing gcc and/or the linker as to the final existence of this function, so
we do get the code for it but not debuginfo.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
2015-07-21 15:01 [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide dsmith at redhat dot com
2015-07-21 18:01 ` [Bug translator/18701] " jistone at redhat dot com
@ 2015-07-21 20:06 ` jistone at redhat dot com
2017-10-11 10:44 ` mark at klomp dot org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jistone at redhat dot com @ 2015-07-21 20:06 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=18701
--- Comment #2 from Josh Stone <jistone at redhat dot com> ---
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1245346
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
2015-07-21 15:01 [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide dsmith at redhat dot com
2015-07-21 18:01 ` [Bug translator/18701] " jistone at redhat dot com
2015-07-21 20:06 ` jistone at redhat dot com
@ 2017-10-11 10:44 ` mark at klomp dot org
2017-10-11 10:49 ` mjw at fedoraproject dot org
2018-10-18 18:37 ` fche at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: mark at klomp dot org @ 2017-10-11 10:44 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=18701
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
2015-07-21 15:01 [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide dsmith at redhat dot com
` (2 preceding siblings ...)
2017-10-11 10:44 ` mark at klomp dot org
@ 2017-10-11 10:49 ` mjw at fedoraproject dot org
2018-10-18 18:37 ` fche at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: mjw at fedoraproject dot org @ 2017-10-11 10:49 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=18701
Mark Wielaard <mjw at fedoraproject dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|mjw at fedoraproject dot org |
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
2015-07-21 15:01 [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide dsmith at redhat dot com
` (3 preceding siblings ...)
2017-10-11 10:49 ` mjw at fedoraproject dot org
@ 2018-10-18 18:37 ` fche at redhat dot com
4 siblings, 0 replies; 6+ messages in thread
From: fche at redhat dot com @ 2018-10-18 18:37 UTC (permalink / raw)
To: systemtap
https://sourceware.org/bugzilla/show_bug.cgi?id=18701
Frank Ch. Eigler <fche at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |fche at redhat dot com
Resolution|--- |OBSOLETE
--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
appears ok on f28 analogue ksys_fadvise64_64.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-10-18 18:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-21 15:01 [Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide dsmith at redhat dot com
2015-07-21 18:01 ` [Bug translator/18701] " jistone at redhat dot com
2015-07-21 20:06 ` jistone at redhat dot com
2017-10-11 10:44 ` mark at klomp dot org
2017-10-11 10:49 ` mjw at fedoraproject dot org
2018-10-18 18:37 ` fche at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).