Bug 18701 - systemtap can't find $return for sys_fadvise64_64 on rawhide
Summary: systemtap can't find $return for sys_fadvise64_64 on rawhide
Status: RESOLVED OBSOLETE
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-21 15:01 UTC by David Smith
Modified: 2018-10-18 18:37 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Smith 2015-07-21 15:01:47 UTC
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.
Comment 1 Josh Stone 2015-07-21 18:01:39 UTC
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.
Comment 2 Josh Stone 2015-07-21 20:06:07 UTC
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1245346
Comment 3 Frank Ch. Eigler 2018-10-18 18:37:08 UTC
appears ok on f28 analogue ksys_fadvise64_64.