[LLVMdev] [lld] Handling non SHF_ALLOC sections.

[Nick Kledzik]

On Sep 16, 2013, at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
> Hi Michael,
> On 9/16/2013 7:23 PM, Michael Spencer wrote:
>> Debug info linking is currently broken due to how we handle reading and
>> laying out non SHF_ALLOC sections. I posted a patch that partially fixes
>> this, but it's both the wrong approach and doesn't handle multiple input
>> files with debug info (wrong relocation values).
>> 
>> The first issue is representing non SHF_ALLOC atoms in the Atom model. We
>> currently don't have a type for this, and DefinedAtom.cpp makes assumptions
>> about the permissions of an Atom based on their type, so it's hard to use
>> an existing type.
There is a couple of ways to model this:
1) SHF_ALLOC=0 sections do not occupy space during execution, so they do not need addresses, so they are not atoms. Instead that section information is modeled as some kind of “attribute” (like a name or content type) of DefinedAtoms or the whole File.  
2) If the dwarf can be parsed into chunks that can be associated with DefinedAtoms, then 
2a) those chunks could be new attributes of an atom, or
2b) those chunks could be atoms themselves (with some defined way to set the name, permissions, etc of those new atoms)

I have looked at breaking up the source line table information in dwarf.  Conceptually, it is a table of pc ranges to source file ranges.  The problem is that it is a compressed table.  Which means you have to decompress it to figure out which rows belong to which atoms. 

So the big question, is should lld parse dwarf into some internal representation (like it does for sections into atoms), or should it basically just pass-thru and concatenate the dwarf?

For what is is worth, Apple has purposefully side stepped this issue with our work flow.  The darwin linker always ignores all dwarf debug info in .o files.  Instead, it records the code ranges along with the path to .o files into “debug notes” it puts in the linker output file.  Our debugger, when it needs debug info for a range, looks at the notes, finds the original .o file and uses the dwarf from it.

-Nick


> Can we parse the Debug sections into atoms too ? This way we could associate Debug information associated with DefinedAtoms (seperate reference types, probably).
> 
> The advantage of this approach would be that Garbage collection would remove all the unneeded references automatically when the definedatom is removed.
> 
> I think Nick also mentioned about a similiar way a while back.