I think we have 

STT_FILE/STT_OBJECT/STT_NOTYPE

The STT_FILE is just a symbol for the compiler to stick meta data
The 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.

<blockquote style='border-left:2px solid #CCCCCC;padding:0 1em' class="quote dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Nick Kledzik wrote</div>
<div class="quote-message">
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
<a href="/user/SendEmail.jtp?type=node&node=49918&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
</div>
</div></blockquote>



        
        
        
<br/><hr align="left" width="300" />
View this message in context: <a href="http://llvm.1065342.n5.nabble.com/LLD-AbsoluteAtoms-tp49910p49918.html">Re: LLD AbsoluteAtoms</a><br/>
Sent from the <a href="http://llvm.1065342.n5.nabble.com/LLVM-Dev-f3.html">LLVM - Dev mailing list archive</a> at Nabble.com.<br/>