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

[Greg Clayton]

>From a debugger perspective the current method with many line tables is very much preferred. Every debugger that I know of currently will associate a line table with a class that represents a compile unit. The main issue is if we don't have correct .debug_aranges made by the compiler and we end up using the line table data to make address ranges for all individual compile units, then we end up with 1000 compile units all claiming to have the same address range. So we might end up looking up an address and finding always in the first compile unit (because its line table suggests this to be the case since all compile units will point to the same line table in the .debug_line section) and if the debuggers aren't careful, they might end up saying the address resolves to the first compile unit. In LLDB, I believe we will make sure something other that just a line table entry from a compile unit matches (we want to find a function whose address range contains the address) before we say it matches. 

So I say if 1.2x properly organizes the data as it should be represented, then that is fine. I also remember seeing wayyyy to many files in the prologue, so if space savings are needed, I would look closely at all files in the prologue and make sure they are correctly in the table, uniqued properly and used by the compile unit or a line entry.

Greg Clayton

On Feb 3, 2014, at 12:48 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> 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.
> 
> It is probably about this, yes.
> 
> I am a bit lost at why the current behavior is faster. My
> understanding is that to map an address to a file and line the
> debugger must
> 
> 1 - Do a binary search to find the compile unit
> 2 - Given the compile unit, follow the link to find its entries in .debug_line
> 3 - Do a binary search on those to find the line.
> 
> On the current behavior we get multiple compile units, each with a
> small(ish) number of files, so we have two "real" binary searches.
> 
> On the old (or current via a .s) setup we have a single compile unit
> which has every single file. This degenerates the first search since
> there is only one item and makes the second search a bit slower.
> 
> In the end, it is still a search over more or less the same number of items.
> 
> Should we at least have an option for the old behavior? A  1.2X
> increase in the size of .debug_line is probably undesirable for some
> uses.
> 
> Cheers,
> Rafael