[lto] PATCH: Read DWARF 3

[Daniel Berlin]

Mark Mitchell wrote:
> Kenneth Zadeck wrote:
> 
>>> Kenny, Jim Blandy suggested that it might make sense for us to use
>>> DWARF for the bodies of functions as well as for declarations.  The
>>> idea here would be to define a bunch of new DWARF tags and attributes
>>> to represent TREE nodes.  So, this is a syntactic choice (i.e., format
>>> of bits on disk), not a semantic choice about what the content actuall
>>> is.  There's nothing magic about the idea, but it would let us
>>> leverage a pre-existing file format that (a) provides a reasonable
>>> representation for tree-structured data (like TREE), (b) which has
>>> some encoding tricks for compactness, and (c) for which we already
>>> have readers, writers, and file dumpers.  So, I think it's an idea
>>> worth thinking about.
>>>
>>>   
>> Lets say that I do this.  Does each function go in it's own dwarf
>> section or do I cram all of the function bodies in the same section?
> 
> You could do it either way, in theory.  DWARF has the ability to refer
> to separate sections for any subtree, so we can have the main debugging
> information point at "that section over there" for the body of the
> function.  There will doubtless be a little complexity to make that
> work, but, entirely independent of LTO, separated subtrees is a feature
> we should implement anyhow to better handle COMDAT.
> 
I was actually about to ask a related question:

Do you ever plan on supporting multiple DW_TAG_compile_unit's in the
same object file?

If so, i'll happily make the code work for this *now*.
This involves
1. Reading the abbrev offsets for each compilation unit by actually
looking at what the abbrev offset in the compilation unit header.
2. Supporting more than one compilation unit in memory at once, by
keeping a compilation unit structure, and having the abbrevs for each CU
stored in it.
3. Making a pass over the entire info section, recording CU start
location, so we know which CU to read for a given DW_form_ref_addr.

Doing reading the way you do now, where you assume there is one compile
unit to be read at a time, and thus, one set of abbrevs to be read at a
time was something GDB did for years.

A *large* amount of the reader had to be changed to pass a compilation
unit structure around properly, so that we could support
DW_form_ref_addr (which is something you will likely need for compaction
across CU's).

It's just one of those things known to be a pain in the ass from
experience, and i'm happy to just code up the necessary compilation unit
context and send in a patch if we ever plan on supporting this, rather
than retrofitting code later.

--Dan