[LLVMdev] LLD AbsoluteAtoms

[Nick Kledzik]

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.

-Nick

> 
> Shankar Easwaran
> 
> On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <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         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121015/559a441b/attachment.html>