[Bug debug/20268] g++ generates incomplete debug information for given testcase with optimization

["fnf at specifixinc dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From fnf at specifixinc dot com  2005-03-02 16:01 -------
Subject: Re:  g++ generates incomplete debug information for given testcase with optimization

On Tuesday 01 March 2005 22:49, dberlin at gcc dot gnu dot org wrote:

> In particular, it is possible we are missing some inlined subroutine
> dies.

Keeping in mind my previous email that I'm not familiar with how gcc records
and tracks the source information, why can it maintain the correct file and
line number info on a per instruction basis but not the scoping info?

Is gcc currently capable of tracking discontiguous scopes that would
get produced by code motion from optimization, where instructions from
different scopes get interleaved in the instruction stream?  Or is it
just the case that it currently isn't make full use of the DWARF
DW_AT_ranges attribute to provide more fine grained matching of
individual instructions with the scope that generated them?

> However, i wouldn't necessarily believe the output of addr2line either.

Exactly, which is why I dug through the DWARF info to verify that there
was no scope information for a significant number of instructions, other
than the scope for main.

> Looking at your output, i only see a small number of things outside the scopes
> that "don't belong to main".
> Or am i looking at the wrong thing?

I'm not very familiar with C++ so I can't say for sure that the code
that appears to belong to main from the existing scope information
actually does or doesn't come from some inlined C++ generated
function.  But in those cases I'd expect the file and line number to
be in t.cc not some C++ include file.

-Fred



------- Additional Comments From fnf at specifixinc dot com  2005-03-02 16:01 -------
Subject: Re:  g++ generates incomplete debug information for given testcase with optimization

> Is there a way to produce the output you gave easily?

No, I had to run readelf to dump the dwarf info and then sift through
that by hand to extract the scope information and match the outermost
scopes up with their code address ranges.

> Also why do you think gcc should produce good debug information with
> optimizations since scheduling can change ording of instructions so
> it causes DW_TAG_inlined_subroutine to be wrong.

Keep in mind that I know nothing about how gcc internally gathers and
maintains the information it needs to match up instructions with the
source code file name, line number, and function.  I have over the
years occasionally poked around in the actual code that generates the
DWARF info, but that is rare.

I guess I would expect that if gcc can maintain correct file and line
number information for a given instruction or set of instructions as
they move around due to code motion for optimization, it should also
be able to maintain the correct association between every instruction
and the source function that generated it.  I.E. we should never see
a situation where the debug information would cause addr2line to put
out something like:

  $ addr2line -v
  GNU addr2line 2.15.95 20050301

  $ addr2line -s -f -e t 0x8048932
  main
  stl_vector.h:273

where it emits inconsistent function name and source code location
information.

While it would be normal to also suspect addr2line of not doing the
right thing in this particular case, this is why I went to the trouble
to dig through the DWARF information to confirm that there really isn't
any scope that includes these addresses other than the outmost scope
for main, from the DIE

 <1><39c1>: Abbrev Number: 111 (DW_TAG_subprogram)
     DW_AT_sibling     : <3d0c>
     DW_AT_external    : 1
     DW_AT_name        : (indirect string, offset: 0x52a): main
     DW_AT_decl_file   : 6
     DW_AT_decl_line   : 5
     DW_AT_type        : <46>
     DW_AT_low_pc      : 0x8048880
     DW_AT_high_pc     : 0x8048c2d

So addr2line only knows that this address (0x8048932) belongs to main
and there is nothing in the debug info scope information to indicate
otherwise.

-Fred




-- 


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