[Bug translator/27469] New: Some probe points locations for inlined functions not in expected places

["wcohen at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27469

            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=13265&action=edit
Simple program with nested inlined functions to demonstrate the issue.

I was comparing where gdb places break points for inlined functions with where
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=.absolute+0x1050 */ $__nptr:char const*
process("/home/wcohen/test2").function("atoi@/usr/include/stdlib.h:361") /*
pc=.absolute+0x1077 */ $__nptr:char const*
process("/home/wcohen/test2").function("f@/home/wcohen/lto_test2.c:9") /*
pc=.absolute+0x1087 */
process("/home/wcohen/test2").function("f@/home/wcohen/lto_test2.c:9") /*
pc=.absolute+0x108e */
process("/home/wcohen/test2").function("g@/home/wcohen/lto_test2.c:4") /*
pc=.absolute+0x1087 */
process("/home/wcohen/test2").function("g@/home/wcohen/lto_test2.c:4") /*
pc=.absolute+0x108e */
process("/home/wcohen/test2").function("main@/home/wcohen/lto_test2.c:14") /*
pc=.absolute+0x1050 */ $argc:int $argv:char**

pc=.absolute+0x1050 for the first atoi inlined is the very first instruction in
main.
pc=.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=.absolute+0x1087 for first call to f pretty much at the f has run and just
before printf is called
pc=.absolute+0x108e for second call to f this looks like it is actually at the
expected position (but argument x isn't accessible)
pc=.absolute+0x1087 for first call to g this looks to happen after g and done
all the work executing
pc=.absolute+0x108e for second call to g this actually looks to be at the
correct place (but argument y isn't accessible)
pc=.absolute+0x1050 since this the entry to actual function main this looks 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.

=> 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 <printf@plt>
=> 0x000000000040108e <+62>:    lea    0x1(%rbx),%esi
   0x0000000000401091 <+65>:    mov    $0x402010,%edi
   0x0000000000401096 <+70>:    xor    %eax,%eax
   0x0000000000401098 <+72>:    call   0x401030 <printf@plt>

for g in test2:
=> 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 <printf@plt>
=> 0x000000000040108e <+62>:    lea    0x1(%rbx),%esi
   0x0000000000401091 <+65>:    mov    $0x402010,%edi
   0x0000000000401096 <+70>:    xor    %eax,%eax
   0x0000000000401098 <+72>:    call   0x401030 <printf@plt>

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
=> 0x0000000000401051 <+1>:     mov    $0xa,%edx
   0x0000000000401056 <+6>:     push   %rbx
   0x0000000000401057 <+7>:     mov    %rsi,%rbx

   0x0000000000401064 <+20>:    call   0x401040 <strtol@plt>
=> 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 information
on where to place the breakpoints in inlined functions.

-- 
You are receiving this mail because:
You are the assignee for the bug.