<div dir="ltr"><div class="gmail_extra"><div>On Mon, Sep 16, 2013 at 7:16 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br></div><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Sep 16, 2013, at 6:48 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>> wrote:<br>
> Hi Michael,<br>
> On 9/16/2013 7:23 PM, Michael Spencer wrote:<br>
>> Debug info linking is currently broken due to how we handle reading and<br>
>> laying out non SHF_ALLOC sections. I posted a patch that partially fixes<br>
>> this, but it's both the wrong approach and doesn't handle multiple input<br>
>> files with debug info (wrong relocation values).<br>
>><br>
>> The first issue is representing non SHF_ALLOC atoms in the Atom model. We<br>
>> currently don't have a type for this, and DefinedAtom.cpp makes assumptions<br>
>> about the permissions of an Atom based on their type, so it's hard to use<br>
>> an existing type.<br>
</div>There is a couple of ways to model this:<br>
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.<br>
</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) If the dwarf can be parsed into chunks that can be associated with DefinedAtoms, then<br>
2a) those chunks could be new attributes of an atom, or<br></blockquote><div><br></div><div>Again, weird for the above reasons.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2b) those chunks could be atoms themselves (with some defined way to set the name, permissions, etc of those new atoms)<br></blockquote><div><br></div><div>This makes sense for the cases where we want to parse DWARF, but it doesn't handle other non SHF_ALLOC sections.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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?<br></blockquote><div><br></div><div>
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.</div>
<div><br></div><div>- Michael Spencer</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<span><font color="#888888"><br>
-Nick<br>
</font></span><div><div><br>
<br>
> Can we parse the Debug sections into atoms too ? This way we could associate Debug information associated with DefinedAtoms (seperate reference types, probably).<br>
><br>
> The advantage of this approach would be that Garbage collection would remove all the unneeded references automatically when the definedatom is removed.<br>
><br>
> I think Nick also mentioned about a similiar way a while back.<br>
<br>
</div></div></blockquote></div><br></div></div>