[LLVMdev] [lld] Handling non SHF_ALLOC sections.

[Shankar Easwaran]

On 9/16/2013 9:16 PM, Nick Kledzik wrote:
> 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.
I think LLVM DebugInfo has API's to deal with debug information, isnt it ?
> 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?
The penalty is only when garbage collection is done. The linker might 
store extra debug information. This could be a corner case though.
> 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.
For ELF, until DWARF5 is adopted, I assume we cant ignore Debug Info. 
Also certain customer apps might want to still maintain debug 
information in the executables(we have couple of such assumptions).

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation