https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
--- Comment #9 from Jan Kratochvil <jan.kratochvil at redhat dot com> --- -O2 -g does not show this problem so I am testing it with -O0 -g below: g++ (GCC) 4.7.3 20130221 (prerelease) 0x0000000000400748 <+4>: sub $0x10,%rsp => 0x000000000040074c <+8>: mov 0x200906(%rip),%eax # 0x601058 <b> 0x0000000000400752 <+14>: add $0x3,%eax .debug_line: [0x00000078] Special opcode 36: advance Address by 2 to 0x400744 and Line by 3 to 30 [0x00000079] Special opcode 118: advance Address by 8 to 0x40074c and Line by 1 to 31 [0x0000007a] Extended opcode 4: set Discriminator to 1 [0x0000007e] Advance PC by constant 17 to 0x40075d [0x0000007f] Special opcode 104: advance Address by 7 to 0x400764 and Line by 1 to 32 Not OK, the line 5 of inlined function foo() is not present there at all. g++ (GCC) 6.0.0 20160205 (Red Hat 6.0.0-0.10) 0x0000000000400645 <+4>: sub $0x10,%rsp => 0x0000000000400649 <+8>: mov 0x2009e5(%rip),%eax # 0x601034 <b> 0x000000000040064f <+14>: add $0x3,%eax .debug_line: [0x00000104] Special opcode 50: advance Address by 3 to 0x400641 and Line by 3 to 30 [0x00000105] Advance Line by -25 to 5 [0x00000107] Special opcode 117: advance Address by 8 to 0x400649 and Line by 0 to 5 [0x00000108] Advance Line by 26 to 31 [0x0000010a] Special opcode 173: advance Address by 12 to 0x400655 and Line by 0 to 31 This is basically OK, inlined function foo() is shown for its lines of code. The bug is that in both cases .debug_info does not contain DW_AT_inline-d DW_TAG_subprogram foo() as a child of DW_TAG_subprogram main() with its proper PC range 0x400649..0x400655 excl. This is why GDB shows: 5 /* 5 */ inline void foo(const int &x = (b+3)) (gdb) bt #0 main () at t.cc:5 while GDB should show: 5 /* 5 */ inline void foo(const int &x = (b+3)) (gdb) bt #0 foo (...) at t.cc:5 #1 main () at t.cc:31 But that would be still look wrong as it would show the latter case even after $ gdb -ex start ./t (therefore stopping at line 5 instead of expected line 31) because GDB currently shows the innermost inlined frame after stopping at a breakpoint. That is IMO a GDB bug and Fedora GDB was showing the outermost frame (so that then one "step"ped into the inlined functions without changing $pc) for some time. But current Fedora GDB is back again aligned with upstream GDB to the "buggy" behavior.
