[LLVMdev] [lld] Handling non SHF_ALLOC sections.
bigcheesegs at gmail.com
Tue Sep 17 11:56:47 PDT 2013
On Mon, Sep 16, 2013 at 7:16 PM, Nick Kledzik <kledzik at apple.com> wrote:
> On Sep 16, 2013, at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org>
> > 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.
> >> currently don't have a type for this, and DefinedAtom.cpp makes
> >> about the permissions of an Atom based on their type, so it's hard to
> >> 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.
It's weird to not treat them as atoms, as they still have relocations and a
lot of other things atoms have. They still need to be laid out within the
file, and need to be able to refer to other atoms.
> 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
Again, weird for the above reasons.
> 2b) those chunks could be atoms themselves (with some defined way to set
> the name, permissions, etc of those new atoms)
This makes sense for the cases where we want to parse DWARF, but it doesn't
handle other non SHF_ALLOC sections.
> 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?
There seem to be major size savings to be had to compressing DWARF. I think
we should look at it on a case by case basis to see how much size reduction
we get vs how much it slows down the link. But we definitely need a
- Michael Spencer
> 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.
> > 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
> > I think Nick also mentioned about a similiar way a while back.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev