[LLVMdev] LLD AbsoluteAtoms

shankarke shankarke at gmail.com
Mon Oct 15 11:38:40 PDT 2012

I think we have STT_FILE/STT_OBJECT/STT_NOTYPEThe STT_FILE is just a symbol
for the compiler to stick meta dataThe STT_OBJECT is a symbol for the
compiler to stick more meta data (GLIBC version etc)The STT_NOTYPE is a
symbol created by the linker so that it can refer to then (either in
crt0.0/dynamic linker) I dont know if these symbols can be overridden.
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:> 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_______________________________________________LLVM Developers
> mailing list

> LLVMdev at .uiuc

> http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

View this message in context: http://llvm.1065342.n5.nabble.com/LLD-AbsoluteAtoms-tp49910p49918.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121015/e726cdae/attachment.html>

More information about the llvm-dev mailing list