[Bug symtab/26243] Handle line number 0 in line table produced by clang

[palves at redhat dot com]

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

--- Comment #11 from Pedro Alves <palves at redhat dot com> ---
I tried my patch against the testcase from Tom's proposed patch on the mailing
list, and that results in:

 Running
/home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp
...
 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
 KPASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint:
bar1_label_3 (PRMS gdb/nnnnn)
 KPASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint:
bar2_label_3 (PRMS gdb/nnnnn)

The FAIL is because GDB is not figuring out the length of the "bar2" function
correctly:

 (gdb) disassemble bar2
 Dump of assembler code for function bar2:
   0x00000000004004c0 <+0>:     push   %rbp
   0x00000000004004c1 <+1>:     mov    %rsp,%rbp
   0x00000000004004c4 <+4>:     mov    $0x1,%edi
   0x00000000004004c9 <+9>:     call   0x400487 <foo>
   0x00000000004004ce <+14>:    mov    $0x2,%edi
   0x00000000004004d3 <+19>:    call   0x400487 <foo>
 End of assembler dump.
 (gdb) q

So after that "next", the program stops at an address outside of the function,
and so the patch's still-in-same-function logic doesn't apply.

I.e., seems like either there's a bug elsewhere, where bar2's length is
determined, or the testcase has a bug.  The other two calls to foo should be
part of the function too.

Interestingly, if you try to set a breakpoint just by number using
Tom's testcase (with or without his proposed fix), GDB crashes...:

 (gdb) b 54
 Aborted (core dumped)

Sigh.

-- 
You are receiving this mail because:
You are on the CC list for the bug.