[Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide

albert.aribaud at 3adev dot fr
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.
Reply | Threaded
Open this post in threaded view
|

[Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide

albert.aribaud at 3adev dot fr
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.
Reply | Threaded
Open this post in threaded view
|

[Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
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.
Reply | Threaded
Open this post in threaded view
|

[Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
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.
Reply | Threaded
Open this post in threaded view
|

[Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
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.
Reply | Threaded
Open this post in threaded view
|

[Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide

albert.aribaud at 3adev dot fr
In reply to this post by albert.aribaud at 3adev dot fr
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.