[LLVMdev] LLD AbsoluteAtoms
sidneym at codeaurora.org
Tue Oct 16 06:51:19 PDT 2012
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?
.type absSymbol, @object
.type absSymbol2, @object
>> 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.
>> > 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
>> >> 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/>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-dev