[LLVMdev] [lld] Handling non SHF_ALLOC sections.

[Michael Spencer]

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>
> 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.
>

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
passthrough mode.

- 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.
>
> -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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/69fe0a7b/attachment.html>