[Bug debug/65821] [4.9/5/6 regression] incorrect debug line # info for main

[jan.kratochvil at redhat dot com]

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.