------- 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