search for: absoluteatom

...ilar 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...

...o, "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 > Convention...

...ation 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 > > Shankar Easwaran > > On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple...

...gt;>> > >>> 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 > giv...

...Type" 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 thi...

...t;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...

...p symbol * RSS_GP0 - gp0 value taken from the .MIPS.options or .reginfo section * RSS_LOC - address of location being relocated So the problem is how to store these four constants in the lld::Reference object. The RSS_UNDEF is obviously not a problem. To represent the RSS_GP value I can set an AbsoluteAtom created for the "_gp" as the reference's target. But what about RSS_GP0 and RSS_LOC? I am considering the following approaches but cannot select the best one: a) Create AbsoluteAtom for each of these cases and set them as the reference's target. The problem is that these atoms...

...or .reginfo section >> * RSS_LOC - address of location being relocated >> >> So the problem is how to store these four constants in the >> lld::Reference object. >> The RSS_UNDEF is obviously not a problem. To represent the RSS_GP value I >> can >> set an AbsoluteAtom created for the "_gp" as the reference's target. But >> what >> about RSS_GP0 and RSS_LOC? I am considering the following approaches but >> cannot >> select the best one: >> >> a) Create AbsoluteAtom for each of these cases and set them as the >&...

...aken from the .MIPS.options or .reginfo section > * RSS_LOC - address of location being relocated > > So the problem is how to store these four constants in the > lld::Reference object. > The RSS_UNDEF is obviously not a problem. To represent the RSS_GP value I > can > set an AbsoluteAtom created for the "_gp" as the reference's target. But > what > about RSS_GP0 and RSS_LOC? I am considering the following approaches but > cannot > select the best one: > > a) Create AbsoluteAtom for each of these cases and set them as the > reference's target....

...rather than having the symbols seperately considered in the Driver, on whether we want to add to the deadStripRoot set or not, we can just use the attributes on the atom to place them in the deadStripRoot set / not. On the similiar lines, I think it should become an atom property itself (having absoluteAtoms also have this property set) ? What do you think ? Thanks Shankar Easwaran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130827/1ce82f84/attachment.html>

...ion being relocated > >>> > >>> So the problem is how to store these four constants in the > >>> lld::Reference object. > >>> The RSS_UNDEF is obviously not a problem. To represent the RSS_GP > value I > >>> can > >>> set an AbsoluteAtom created for the "_gp" as the reference's target. > But > >>> what > >>> about RSS_GP0 and RSS_LOC? I am considering the following approaches > but > >>> cannot > >>> select the best one: > >>> > >>> a) Creat...

...tion >>> * RSS_LOC - address of location being relocated >>> >>> So the problem is how to store these four constants in the >>> lld::Reference object. >>> The RSS_UNDEF is obviously not a problem. To represent the RSS_GP value I can >>> set an AbsoluteAtom created for the "_gp" as the reference's target. But what >>> about RSS_GP0 and RSS_LOC? I am considering the following approaches but cannot >>> select the best one: >>> >>> a) Create AbsoluteAtom for each of these cases and set them as the >&gt...

...the problem is how to store these four constants in the > >> >>> lld::Reference object. > >> >>> The RSS_UNDEF is obviously not a problem. To represent the RSS_GP > >> >>> value I > >> >>> can > >> >>> set an AbsoluteAtom created for the "_gp" as the reference's target. > >> >>> But > >> >>> what > >> >>> about RSS_GP0 and RSS_LOC? I am considering the following approaches > >> >>> but > >> >>> cannot > >&gt...

...to store these four constants in the >> >> >>> lld::Reference object. >> >> >>> The RSS_UNDEF is obviously not a problem. To represent the RSS_GP >> >> >>> value I >> >> >>> can >> >> >>> set an AbsoluteAtom created for the "_gp" as the reference's >> target. >> >> >>> But >> >> >>> what >> >> >>> about RSS_GP0 and RSS_LOC? I am considering the following >> approaches >> >> >>> but >> &gt...

...dea for this was to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end. Agreed. On one hand, this sounds like an AbsoluteAtom because it has no content and no section, but has an address. On the other hand, it needs References to the symbols used in its expression and only DefinedAtoms can have content. But DefinedAtoms are normally laid out and assigned addresses. One way to work this in would be to make them Defined...

...on being relocated >>>>> >>>>> So the problem is how to store these four constants in the >>>>> lld::Reference object. >>>>> The RSS_UNDEF is obviously not a problem. To represent the RSS_GP >> value I can >>>>> set an AbsoluteAtom created for the "_gp" as the reference's target. >> But what >>>>> about RSS_GP0 and RSS_LOC? I am considering the following approaches >> but cannot >>>>> select the best one: >>>>> >>>>> a) Create AbsoluteAtom f...

...Global, the atoms that the Reader created should get overridden with the linker created ones. This may also be needed to pul in specific symbols from archive libraries, too. I was thinking to add an interface to ReaderELF which would be called by the driver, but the problem is the DefinedAtom/AbsoluteAtom have which file owns the atom. I was discussing with Michael on this, and he was proposing to add a Pre-Read file. Do you have any other opinions too ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

...If a required symbol name turns out to be defined in a dynamic shared library (and not some object file). A SharedLibraryAtom is the placeholder Atom used to represent that fact. It is similar to an UndefinedAtom, but it also tracks information about the associated shared library. 4) AbsoluteAtom This is for embedded support where some stuff is implemented in ROM at some fixed address. This atom has no content. It is just an address that the Writer needs to fixup any references to point to. > > The readers generate a list of atoms from some object format. > The linke...

...as to allow atoms to have an associated expression tree and would have references to all symbols in that tree. The resolver wouldn't need any special handling for this, and the backend would just need to evaluate the expression at the end. > Agreed. > > On one hand, this sounds like an AbsoluteAtom because it has no content and no section, but has an address. On the other hand, it needs References to the symbols used in its expression and only DefinedAtoms can have content. But DefinedAtoms are normally laid out and assigned addresses. One way to work this in would be to make them Defined...

...der created should get overridden with the linker created ones. >> >> This may also be needed to pul in specific symbols from archive libraries, too. >> >> I was thinking to add an interface to ReaderELF which would be called by the driver, but the problem is the DefinedAtom/AbsoluteAtom have which file owns the atom. >> >> I was discussing with Michael on this, and he was proposing to add a Pre-Read file. >> >> Do you have any other opinions too ? > We have a similar requirement in darwin's ld64 linker, but even more general. Any binary can do the f...