[llvm] r176605 - Debug Info: store the files and directories for each compile unit.

[Greg Clayton]

I believe the problem was that line tables had thousands of files in each line table prologue. 

Smaller is better, that is for sure. DW_AT_ranges attributes on DW_TAG_compile_unit tags have been useless for many years and we never trusted them. We always use the .debug_aranges in order to find out which compile unit contains which address, and even then we verify that there is at least a line table entry or some DWARF info for that address when we do think we have a match (the compile unit could claim to contain [0x1000-0x2000), yet there actually could be a gap in that range and if we found no other address information once we expanded the compile unit, we would continue to the next entry). This easily allowed the DW_TAG_compile_unit to emit a single "max" range using DW_AT_low_pc/DW_AT_high_pc, and then we used that as a guide. I think most debuggers will use the .debug_aranges when it is available. When it isn't, we make a manual pass through all DWARF and make it ourselves. The DW_AT_ranges in the compile unit is not currently considered useful or accurate so we really don't care what is in there beyond the accuracy of the "base address" that is used to compute all DW_AT_ranges and location list ranges for all _other_ tags in the compile unit.

I am not really sure what this bug is about, so I was just guessing above that it was a bug that I filed back in the early LTO days where line tables being emitted had waaaay too many files in the prologue and many files were duplicated in the list.

Greg

On Jan 31, 2014, at 11:07 PM, Eric Christopher <echristo at gmail.com> wrote:

> I was under the impression is was a speed improvement for the
> debugger. Having a smaller line table to look through for a given
> compile unit would let it find a given address faster.
> 
> That said, without ranges for compile units I'm not sure how the
> debugger would know. We have those now, but not then.
> 
> Greg: I'm guessing you made the request, any further insight here? :)
> 
> -eric
> 
> On Fri, Jan 31, 2014 at 8:20 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>> Hi Manman and Eric,
>> 
>> I started looking at what would be needed to properly represent this
>> in a .s file in order to remove the calls to hasRawTextSupport. It
>> looks like we would need a compilation unit id for .file and some
>> directive that produces the offset of a given compilation unit in
>> debug_line. Not too hard, but I am somewhat confused as to what the
>> advantage of having multiple line tables is. From your commit message
>> it sounds like the prologue is duplicated, but  that is not what I am
>> seeing.
>> 
>> As an experiment I compiled clang with lto and -gline-tables-only. The
>> size of the resulting .debug_line section is
>> 
>> via assembly: 0x9b6358 bytes (10.183512 MB)
>> direct:            0xbb7a83 bytes (12.286595 MB)
>> 
>> The version using direct object emission has 1267 line tables. The
>> version using assembly has 1. Sure, that table has 10738 files, but it
>> is still quiet a bit smaller than the total in the direct emission
>> case.
>> 
>> Cheers,
>> Rafael