[Bug debug/20268] With optimization, generating incomplete debug information

["wilson at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-18 05:11 -------
Created an attachment (id=8414)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8414&action=view)
use DW_AT_ranges in DW_AT_inlined_subroutine

Using -dA will add comments to the debug info in the .s file.  This is easy for
gcc hackers to create and read.

I tried looking at one of the problems with your example.  I picked the
tmp.cc:8 line, which is followed by a line from stl_vector.h:221 which claims
to be in function main.  Looking at the .s file, I see that there are two
LBBX/LBEX block labels around the instruction, but no debug info that refers to
these block labels.

Investigating, I find that the situation is as Dan described earlier.  We have
DW_AT_ranges support, but only for lexical blocks, not for inlined subroutine
blocks.  This is trivial to fix.  The patch I am attaching to the pr does this.


Recompiling, the .s file looks reasonable now, the stray insn now is inside a
block that is in the DW_AT_ranges of a DW_AT_inlined_subroutine which should
give the result we want.

Trying addr2line again, I see no difference, but this turns out to be a bfd
issue.	The scan_unit_for_functions code in bfd/dwarf2.c handles DW_AT_lo_pc
and DW_AT_high_pc, but not DW_AT_ranges, which means it is not able to find
this block when it checks address ranges.  Presumably this is something you can
fix.  Without DW_AT_ranges support here, my patch will likely make things worse
than they already are.	With DW_AT_ranges support here, my patch should make
things better.

There is also the issue of whether gdb will be happy with this.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268