Re: [Valgrind-developers] precise stack traces in presence of inlining

[Konstantin S. <kon...@gm...>]

>> Shall I file a bug (feature request)?
>
> If you can show that GDB does produce the same stack traces in both
> cases, then yes.  But I doubt it can do that.
>

I've just learned that this feature has been implemented in gdb few
days ago. :)

2009-06-27  Daniel Jacobowitz  <da...@co...>
           Jan Kratochvil  <jan...@re...>

       * NEWS: Document inlined function support.
       * Makefile.in (SFILES): Add inline-frame.c.
       (COMMON_OBS): Add inline-frame.o.
       * block.c (contained_in): Rewrite to use lexical nesting.
       ...

>From NEWS:

* Inlined functions are now supported.  They show up in backtraces, and
the "step", "next", and "finish" commands handle them automatically.

$ gdb64-cvs ./a.out
GNU gdb (GDB) 6.8.50.20090701-cvs
...
(gdb) b main
Breakpoint 1 at 0x4003a0: file inline_test.c, line 12.
(gdb) r

Breakpoint 1, main () at inline_test.c:12
12      int main() {
(gdb) s
14        bar(&uninitialized_stack[1]);
(gdb) s
bar (p=0x7fffffffdd04) at inline_test.c:9
9         foo(p);
(gdb) s
foo (p=0x7fffffffdd04) at inline_test.c:4
4         if (*p == 777) printf("777\n");
(gdb) bt
#0  foo (p=0x7fffffffdd04) at inline_test.c:4
#1  bar (p=0x7fffffffdd04) at inline_test.c:9
#2  0x00000000004003ae in main () at inline_test.c:14
(gdb) disas
Dump of assembler code for function bar:
0x0000000000400380 <bar+0>:     cmpl   $0x309,(%rdi)
0x0000000000400386 <bar+6>:     je     0x400390 <bar+16>
0x0000000000400388 <bar+8>:     repz retq
0x000000000040038a <bar+10>:    nopw   0x0(%rax,%rax,1)
0x0000000000400390 <bar+16>:    mov    $0x40047c,%edi
0x0000000000400395 <bar+21>:    jmpq   0x4005e8 <puts@plt>
End of assembler dump.

Disassembly clearly shows foo was inlined; yet it shows in the stack trace :-)


--kcc