LLD AbsoluteAtoms

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.

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]

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

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.

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.

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.

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

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

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

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?

This example:
.file "abs.S"
.globl absSymbol
.set absSymbol,0xC0000
.type absSymbol, @object

.local absSymbol2
.set absSymbol2,0xD0000
.type absSymbol2, @object