<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 15, 2012, at 9:06 PM, Shankar Kalpathi Easwaran wrote:</div><blockquote type="cite">The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. <br><br>I dont think the linker has to add a absolute symbol by figuring out the translation unit.<br></blockquote><div>Then we are in agreement. Sid started this thread with the suggestion of adding new content types to AbsoluteAtoms so as to encode STT_FILE symbols. I said we don't need to new content type, but rather that STT_FILE should map to the lld::File's translationUnitSource instead of to an Atom.</div><div><br></div><div>-Nick</div><div><br></div><blockquote type="cite">
<br>Shankar Easwaran<br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Oct 15, 2012, at 4:00 PM, Sid Manning wrote:<br>
<br>
> On 10/15/12 12:01, Nick Kledzik wrote:<br>
>><br>
>> On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote:<br>
>>><br>
>>> I think that absolute atoms will need something similar to, "contentType" added.<br>
>>><br>
>>> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a contentType method to AbsoluteAtom and sprinkled changes around to make this work.<br>
>> Tell me more about the semantics of STT_FILE. The goal is not just to pass through ELF-isms. The goal is to define a really good model and translate each object format into that model. A web search for STT_FILE gives:<br>
>><br>
> In this case for it may be an ELF'ism, when<br>
> st_info == STB_LOCAL | STT_FILE<br>
> st_shndx == SHN_ABS<br>
><br>
> Then st_value will probably be zero and this symbol's name should match<br>
> the name of the originating source file.<br>
</div>The lld::File class has a method translationUnitSource() that (if available) returns the path to the source file that created this object file. If this matches the semantics of STB_LOCAL | STT_FILE, then the reader could use that SHN_ABS symbol to populate an ivar that translationUnitSource() returns. That is, that symbol converts into a File attribute and not into an Atom.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Nick<br>
</font></span><div class="im HOEnZb"><br>
><br>
> Currently there is only one qualifying characteristic a symbol must have in order to be converted into an absolute atom, st_shndx == SHN_ABS. The problem is that symbols with this attribute can be of multiple (at least 2) types, STT_FILE, STT_OBJECT. The attributes of the original input must be preserved in the output file.<br>
><br>
> Maybe the reader should be pickier about what it is calling an absolute atom and only making them when type == STT_OBJECT is true. I have a patch that adds contentType to absolute atom rather than just filtering the input, hmm filtering probably would have been easier. I will submit the patch anyway later today or tomorrow.<br>
><br>
> What exactly to do with symbols that live in special sections, SHN_LORESERVE and up has been an ongoing discussion. If we keep the object file format reader classes final adding target specific hooks, like kindHandler seems like a possible option.<br>
><br>
><br>
><br>
><br>
><br>
>>> STT_FILE<br>
>>> Conventionally, the symbol's name gives the name of the source file associated with the object file. A file symbol has STB_LOCAL binding and its section index is SHN_ABS. This symbol, if present, precedes the other STB_LOCAL symbols for the file. Symbol index 1 of the SHT_SYMTAB is an STT_FILE symbol representing the file itself. Conventionally, this symbols is followed by the files STT_SECTION symbols, and any global symbols that have been reduced to locals.<br>
>><br>
>> This sounds like these symbols are not really about absolute address (e.g. ROM), but a way to sneak meta data (like source file name) into the object file.<br>
>><br>
>><br>
>><br>
>>><br>
>>> What do the V1 suffixes mean in the Native code? I had to add a new Attributes array to for the Absolute atoms and simply used, NCS_AttributesArrayV2 following the lead of NCS_ReferencesArrayV[12]<br>
>><br>
>> The V1 is for for when the file format is eventually stable and we need to support new features. We are not there yet.<br>
>><br>
>> -Nick<br>
><br>
><br>
> --<br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
</div><div class="HOEnZb"><div class="h5"><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>
</blockquote></div><br></body></html>