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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Feb 3 12:48:42 PST 2014


> 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



More information about the llvm-commits mailing list