This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Tue, 21 Jul 2015 18:01:39 +0000
- Subject: [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide
- Auto-submitted: auto-generated
- References: <bug-18701-6586 at http dot sourceware dot org/bugzilla/>
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.