[LLVMdev] LLD AbsoluteAtoms

[Nick Kledzik]

On Oct 15, 2012, at 4:00 PM, Sid Manning wrote:

> On 10/15/12 12:01, Nick Kledzik wrote:
>> 
>> On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote:
>>> 
>>> I think that absolute atoms will need something similar to, "contentType" added.
>>> 
>>> 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.
>> 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:
>> 
> In this case for it may be an ELF'ism, when
> st_info == STB_LOCAL | STT_FILE
> st_shndx == SHN_ABS
> 
> Then st_value will probably be zero and this symbol's name should match
> the name of the originating source file.
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.

-Nick 

> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 
>>> STT_FILE
>>> 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.
>> 
>> 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.
>> 
>> 
>> 
>>> 
>>> 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]
>> 
>> The V1 is for for when the file format is eventually stable and we need to support new features.  We are not there yet.
>> 
>> -Nick
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation