From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5EA1A3857003; Thu, 25 Feb 2021 16:48:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5EA1A3857003 From: "wcohen at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/27469] New: Some probe points locations for inlined functions not in expected places Date: Thu, 25 Feb 2021 16:48:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new 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: wcohen 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 16:48:32 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27469 Bug ID: 27469 Summary: Some probe points locations for inlined functions not in expected places Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator Assignee: systemtap at sourceware dot org Reporter: wcohen at redhat dot com Target Milestone: --- Created attachment 13265 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D13265&action=3Ded= it Simple program with nested inlined functions to demonstrate the issue. I was comparing where gdb places break points for inlined functions with wh= ere systemtap places probes for the same functions on Fedora 33. Compiled the attached program with: $ gcc -g -O3 -o test2 lto_test2.c Then look at the addresses and arguments systemtap can find for various functions: $ stap stap -v -L 'process("./test2").function("*")' Pass 1: parsed user script and 494 library scripts using 331284virt/95952res/12452shr/83012data kb, in 150usr/40sys/219real ms. process("/home/wcohen/test2").function("atoi@/usr/include/stdlib.h:361") /* pc=3D.absolute+0x1050 */ $__nptr:char const* process("/home/wcohen/test2").function("atoi@/usr/include/stdlib.h:361") /* pc=3D.absolute+0x1077 */ $__nptr:char const* process("/home/wcohen/test2").function("f@/home/wcohen/lto_test2.c:9") /* pc=3D.absolute+0x1087 */ process("/home/wcohen/test2").function("f@/home/wcohen/lto_test2.c:9") /* pc=3D.absolute+0x108e */ process("/home/wcohen/test2").function("g@/home/wcohen/lto_test2.c:4") /* pc=3D.absolute+0x1087 */ process("/home/wcohen/test2").function("g@/home/wcohen/lto_test2.c:4") /* pc=3D.absolute+0x108e */ process("/home/wcohen/test2").function("main@/home/wcohen/lto_test2.c:14") = /* pc=3D.absolute+0x1050 */ $argc:int $argv:char** pc=3D.absolute+0x1050 for the first atoi inlined is the very first instruct= ion in main. pc=3D.absolute+0x1077 for the second atoi is actually on the call to strol = rather than the earlier instructions in atoi that set up arguments to strtol pc=3D.absolute+0x1087 for first call to f pretty much at the f has run and = just before printf is called pc=3D.absolute+0x108e for second call to f this looks like it is actually a= t the expected position (but argument x isn't accessible) pc=3D.absolute+0x1087 for first call to g this looks to happen after g and = done all the work executing pc=3D.absolute+0x108e for second call to g this actually looks to be at the correct place (but argument y isn't accessible) pc=3D.absolute+0x1050 since this the entry to actual function main this loo= ks to be correct. The locations that gdb uses for the inlined functions f and g in the program and atoi from the header file look much more reasonable: looking at where gdb places the breakpoints for f in test2. It is set up on= the instruction that implements the ++ operation. =3D> 0x000000000040107c <+44>: lea 0x1(%rbp),%esi 0x000000000040107f <+47>: mov $0x402010,%edi 0x0000000000401084 <+52>: mov %rax,%rbx 0x0000000000401087 <+55>: xor %eax,%eax 0x0000000000401089 <+57>: call 0x401030 =3D> 0x000000000040108e <+62>: lea 0x1(%rbx),%esi 0x0000000000401091 <+65>: mov $0x402010,%edi 0x0000000000401096 <+70>: xor %eax,%eax 0x0000000000401098 <+72>: call 0x401030 for g in test2: =3D> 0x000000000040107c <+44>: lea 0x1(%rbp),%esi 0x000000000040107f <+47>: mov $0x402010,%edi 0x0000000000401084 <+52>: mov %rax,%rbx 0x0000000000401087 <+55>: xor %eax,%eax 0x0000000000401089 <+57>: call 0x401030 =3D> 0x000000000040108e <+62>: lea 0x1(%rbx),%esi 0x0000000000401091 <+65>: mov $0x402010,%edi 0x0000000000401096 <+70>: xor %eax,%eax 0x0000000000401098 <+72>: call 0x401030 What about the aoti calls? Sets breakpoint on the instruction setting up a argument of 10 for the strtol call in the atoi. (gdb) break atoi Breakpoint 4 at 0x401051: atoi. (3 locations) Dump of assembler code for function main: 0x0000000000401050 <+0>: push %rbp =3D> 0x0000000000401051 <+1>: mov $0xa,%edx 0x0000000000401056 <+6>: push %rbx 0x0000000000401057 <+7>: mov %rsi,%rbx 0x0000000000401064 <+20>: call 0x401040 =3D> 0x0000000000401069 <+25>: mov 0x10(%rbx),%rdi 0x000000000040106d <+29>: mov $0xa,%edx 0x0000000000401072 <+34>: xor %esi,%esi 0x0000000000401074 <+36>: mov %rax,%rbp Need to do some more digging to determine where gdb is getting this informa= tion on where to place the breakpoints in inlined functions. --=20 You are receiving this mail because: You are the assignee for the bug.=