[LLVMdev] LLD AbsoluteAtoms

[Sid Manning]

On 10/15/12 23:53, Nick Kledzik wrote:
>
> On Oct 15, 2012, at 9:06 PM, Shankar Kalpathi Easwaran wrote:
>> The object file already has the information that when its STT_FILE and
>> the symbol name is the name of the translation unit already.
>>
>> I dont think the linker has to add a absolute symbol by figuring out
>> the translation unit.
> 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.
>

We will still need a way to get the binding type of the original symbol. 
  Is it reasonable to add scope to AbsoluteAtom?

This example:
.file "abs.S"
.globl absSymbol
.set absSymbol,0xC0000
.type absSymbol, @object

.local absSymbol2
.set absSymbol2,0xD0000
.type absSymbol2, @object



> -Nick
>
>>
>> Shankar Easwaran
>>
>> On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple.com
>> <mailto:kledzik at apple.com>> wrote:
>>
>>
>>     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
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>>     http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation