[LLVMdev] LLD AbsoluteAtoms

[Shankar Kalpathi Easwaran]

Hi Nick,

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.

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/b6137a90/attachment.html>