From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93859 invoked by alias); 21 Jul 2015 18:01:49 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 93808 invoked by uid 48); 21 Jul 2015 18:01:39 -0000 From: "jistone at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/18701] systemtap can't find $return for sys_fadvise64_64 on rawhide Date: Tue, 21 Jul 2015 18:01:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jistone at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q3/txt/msg00047.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=18701 Josh Stone changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jistone at redhat dot com --- Comment #1 from Josh Stone --- 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.