<div dir="ltr"><div class="gmail_extra"><div>On Mon, Sep 16, 2013 at 6:48 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br></div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Michael,<div class="im"><br>
<br>
On 9/16/2013 7:23 PM, Michael Spencer wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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>
</blockquote></div>
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.</blockquote><div><br></div><div>You can't just parse it by byte ranges and pull some out. You would actually need to parse the DWARF and rewrite it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The next problem is in the ELF writer. It currently cannot handle<br>
AtomSections that are not in a segment as file offsets and addresses are<br>
never set. This means that assignOffsets is not called, and that the atoms<br>
within are never added to the _atomToAddressMap. However, we can't just add<br>
them to that map with their virtual address, as they don't have a virtual<br>
address. We need to use the symbol value, which is the offset into the<br>
section. My current hack to fix this is to call<br>
assignVirtualAddresses(-<u></u>fileoffset) and then explicitly added them to the<br>
_atomToAddressMap.<br>
<br>
Any ideas for the proper fix here?<br>
</blockquote></div>
There is a way that we can handle this without lot of tweaks.<br>
<br>
a) Assign the debug sections part of a linker internal segment(the segment would not appear in the output file), hasOutputSegment will return true for a debug section.<br>
<br>
b) Around lines 623, in DefaultLayout, we find out if the section is associated with the special debug section, we add this sepecial segment to the list of segments<br></blockquote><div><br></div><div>The problem with this is that it's not just debug. We need to properly implement ELF semantics (ok, really gnu-ld semantics and the ELF spec doesn't say what should happen here (or anywhere really)). The semantics seem to be that the value of symbols in non SHF_ALLOC sections is their offset within the section.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
c) Around lines 731 in DefaultLayout.h, we compare the segment type against the linker internal segment types, and assign offsets for the debug section. Lets not set the virtual addresses for these sections. If there is a need for assigning virtual addresses, you could change the second loop that assigns virtual addresses to deal with that too.<br>

<br>
Thanks<span class=""><font color="#888888"><br>
<br>
Shankar Easwaran<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">- Michael Spencer<br></div><div class="gmail_extra"><br></div></div>