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] -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
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
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>
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. 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