Shankar Easwaran
2015-Feb-09 20:24 UTC
[LLVMdev] [lld] Representation of lld::Reference with a fake target
Hi, The round trip passes just tries to load a *complete* object file in YAML/Native format back. The internal state should be the complete object file in native/yaml format. If some state is not recorded and that is really needed in the writer, we should add that to the Atom model. Shankar Easwaran On 2/9/2015 1:29 PM, Rui Ueyama wrote:> I want to bring this again because I think it's important. > > It doesn't make sense to store and load intermediate atoms/references in > the middle of link, is it? Teaching LLD about how to read from YAML or > Native object file is fine, and we probably want to teach LLD about how to > emit a re-linkable object file in YAML or Native file. But the round-trip > tests do more than that, right? The tests require more -- dumping linker > internal state to a file and reading it correctly. > > On Mon, Feb 9, 2015 at 4:33 AM, Denis Protivensky < > dprotivensky at accesssoftek.com> wrote: > >> A bit off topic: ARM Group relocations define a logical set of consequent >> instructions to be relocated to form one single address. For such >> relocations a 1 to 1 relation is also met, so no need of special processing >> in applyRelocation. >> >> Concerning native format: it also introduced unneeded code complexity to >> me when I wanted to set calculated relocation addend back into the >> Reference object in the relocation handler to simplify further processing. >> Since it crashed in tests because of native format conversion, I needed to >> keep calculated addend to pass it along the handlers instead of just >> calling ref.addend(). >> >> - Denis. >> >> >> On 02/08/2015 08:42 PM, Shankar Easwaram <shankarke at gmail.com> >> <shankarke at gmail.com> wrote: >> >> ARM has a concept of Group relocations, which applies relocations >> considering them as one set may be we should consider extending apply >> relocation. What do you think? >> >> >>> On Feb 8, 2015, at 04:50, Simon Atanasyan <simon at atanasyan.com> >> <simon at atanasyan.com> wrote: >>> Nick, >>> >>> Right now I try to implement exactly the same approach. I split a >>> relocation record on up to three separate relocations. But there are >>> two problems on this way. >>> >>> The first one is how to represent some additional data provided in the >>> relocation record. That is why I asked the initial question in this >>> thread. The current solution is to extend the `Reference` class and >>> add one more attribute to it. >>> >>> The second problem is how to handle these three relocations. Now the >>> `TargetRelocationHandler::applyRelocation()` method called one-by-one >>> for each reference. That is not applied to the MIPS N64 ABI >>> relocations. In that case we need to calculate the first one, save the >>> result, calculate the second one using result from the first step, >>> repeat that for the third relocations and only at the end check the >>> final result on overflow and apply it to the location. My current idea >>> is to allow a target specific code to handle the loop over atom's >>> references now hardcoded in the `AtomSection<ELFT>::write` method. >>> >>>> On Sun, Feb 8, 2015 at 3:21 AM, Nick Kledzik <kledzik at apple.com> >> <kledzik at apple.com> wrote: >>>> Simon, >>>> >>>> Sounds like the instruction relocating is so complicated that ELF >> requires up to three relocation records to encode how to fix up one >> instruction. If that is the case, why not do the same and have up to three >> Reference objects on the same atom offset to record the same info? I >> thought that was model that the ELF part of lld was using - there is a >> one-to-one mapping of ELF reloc to lld References. >>>> Or am I misunderstanding the issue? >>>> >>>> -Nick >>>> >>>> >>>>> On Feb 5, 2015, at 12:22 PM, Simon Atanasyan <simon at atanasyan.com> >> <simon at atanasyan.com> wrote: >>>>> Hi, >>>>> >>>>> I need an advice on implementation of a very specific kind of >> relocations >>>>> used by MIPS N64 ABI. As usual the main problem is how to pass target >> specific >>>>> data over Native/YAML conversion barrier. >>>>> >>>>> In this ABI relocation record r_info field in fact consists of five >> subfields: >>>>> * r_sym - symbol index >>>>> * r_ssym - special symbol >>>>> * r_type3 - third relocation type >>>>> * r_type2 - second relocation type >>>>> * r_type - first relocation type >>>>> >>>>> Up to three these relocations applied one by one. The first relocation >> uses >>>>> an addendum from the relocation record. Each subsequent relocation >> takes as >>>>> its addend the result of the previous operation. Only the final >> operation >>>>> actually modifies the location relocated. The first relocation uses as >>>>> a reference symbol specified by the r_sym field. The third relocation >>>>> assumes NULL symbol. >>>>> >>>>> The most interesting case is the second relocation. It uses the special >>>>> symbol value given by the r_ssym field. This field can contain four >>>>> predefined values: >>>>> * RSS_UNDEF - zero value >>>>> * RSS_GP - value of gp 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 are fake and should not go to the >>>>> symbol table. >>>>> One more problem is to select unique names for these atoms. >>>>> b) Use two high bits of lld::Reference::_kindValue field to encode >>>>> RSS_xxx value. >>>>> Then decode these bits in the RelocationHandler to calculate result >>>>> of relocation. >>>>> In that case the problem is how to represent a relocation kind >>>>> value in YAML format. >>>>> The simple xxxRelocationStringTable::kindStrings[] array will not >> satisfy us. >>>>> c) Add one more field to the lld::Reference class. Something like the >>>>> DefinedAtom::CodeModel >>>>> field. >>>>> >>>>> Any advices, ideas, and/or objections are much appreciated. >>>>> >>>>> -- >>>>> Simon Atanasyan >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> -- >>> Simon Atanasyan >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/23440e02/attachment.html>
Rui Ueyama
2015-Feb-09 20:30 UTC
[LLVMdev] [lld] Representation of lld::Reference with a fake target
On Mon, Feb 9, 2015 at 12:24 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:> Hi, > > The round trip passes just tries to load a *complete* object file in > YAML/Native format back. > > The internal state should be the complete object file in native/yaml > format. > > If some state is not recorded and that is really needed in the writer, we > should add that to the Atom model. >Again, not only saying we should do something, but please elaborate why you think we should. Otherwise we can't discuss... Shankar Easwaran> > > On 2/9/2015 1:29 PM, Rui Ueyama wrote: > > I want to bring this again because I think it's important. > > It doesn't make sense to store and load intermediate atoms/references in > the middle of link, is it? Teaching LLD about how to read from YAML or > Native object file is fine, and we probably want to teach LLD about how to > emit a re-linkable object file in YAML or Native file. But the round-trip > tests do more than that, right? The tests require more -- dumping linker > internal state to a file and reading it correctly. > > On Mon, Feb 9, 2015 at 4:33 AM, Denis Protivensky <dprotivensky at accesssoftek.com> wrote: > > > A bit off topic: ARM Group relocations define a logical set of consequent > instructions to be relocated to form one single address. For such > relocations a 1 to 1 relation is also met, so no need of special processing > in applyRelocation. > > Concerning native format: it also introduced unneeded code complexity to > me when I wanted to set calculated relocation addend back into the > Reference object in the relocation handler to simplify further processing. > Since it crashed in tests because of native format conversion, I needed to > keep calculated addend to pass it along the handlers instead of just > calling ref.addend(). > > - Denis. > > > On 02/08/2015 08:42 PM, Shankar Easwaram <shankarke at gmail.com> <shankarke at gmail.com><shankarke at gmail.com> <shankarke at gmail.com> wrote: > > ARM has a concept of Group relocations, which applies relocations > considering them as one set may be we should consider extending apply > relocation. What do you think? > > > > On Feb 8, 2015, at 04:50, Simon Atanasyan <simon at atanasyan.com> <simon at atanasyan.com> > > <simon at atanasyan.com> <simon at atanasyan.com> wrote: > > Nick, > > Right now I try to implement exactly the same approach. I split a > relocation record on up to three separate relocations. But there are > two problems on this way. > > The first one is how to represent some additional data provided in the > relocation record. That is why I asked the initial question in this > thread. The current solution is to extend the `Reference` class and > add one more attribute to it. > > The second problem is how to handle these three relocations. Now the > `TargetRelocationHandler::applyRelocation()` method called one-by-one > for each reference. That is not applied to the MIPS N64 ABI > relocations. In that case we need to calculate the first one, save the > result, calculate the second one using result from the first step, > repeat that for the third relocations and only at the end check the > final result on overflow and apply it to the location. My current idea > is to allow a target specific code to handle the loop over atom's > references now hardcoded in the `AtomSection<ELFT>::write` method. > > > On Sun, Feb 8, 2015 at 3:21 AM, Nick Kledzik <kledzik at apple.com> <kledzik at apple.com> > > <kledzik at apple.com> <kledzik at apple.com> wrote: > > Simon, > > Sounds like the instruction relocating is so complicated that ELF > > requires up to three relocation records to encode how to fix up one > instruction. If that is the case, why not do the same and have up to three > Reference objects on the same atom offset to record the same info? I > thought that was model that the ELF part of lld was using - there is a > one-to-one mapping of ELF reloc to lld References. > > Or am I misunderstanding the issue? > > -Nick > > > > On Feb 5, 2015, at 12:22 PM, Simon Atanasyan <simon at atanasyan.com> <simon at atanasyan.com> > > <simon at atanasyan.com> <simon at atanasyan.com> wrote: > > Hi, > > I need an advice on implementation of a very specific kind of > > relocations > > used by MIPS N64 ABI. As usual the main problem is how to pass target > > specific > > data over Native/YAML conversion barrier. > > In this ABI relocation record r_info field in fact consists of five > > subfields: > > * r_sym - symbol index > * r_ssym - special symbol > * r_type3 - third relocation type > * r_type2 - second relocation type > * r_type - first relocation type > > Up to three these relocations applied one by one. The first relocation > > uses > > an addendum from the relocation record. Each subsequent relocation > > takes as > > its addend the result of the previous operation. Only the final > > operation > > actually modifies the location relocated. The first relocation uses as > a reference symbol specified by the r_sym field. The third relocation > assumes NULL symbol. > > The most interesting case is the second relocation. It uses the special > symbol value given by the r_ssym field. This field can contain four > predefined values: > * RSS_UNDEF - zero value > * RSS_GP - value of gp 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 are fake and should not go to the > symbol table. > One more problem is to select unique names for these atoms. > b) Use two high bits of lld::Reference::_kindValue field to encode > RSS_xxx value. > Then decode these bits in the RelocationHandler to calculate result > of relocation. > In that case the problem is how to represent a relocation kind > value in YAML format. > The simple xxxRelocationStringTable::kindStrings[] array will not > > satisfy us. > > c) Add one more field to the lld::Reference class. Something like the > DefinedAtom::CodeModel > field. > > Any advices, ideas, and/or objections are much appreciated. > > -- > Simon Atanasyan > _______________________________________________ > LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- > Simon Atanasyan > > _______________________________________________ > LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/d811bad1/attachment.html>
Shankar Easwaran
2015-Feb-09 21:05 UTC
[LLVMdev] [lld] Representation of lld::Reference with a fake target
On Mon, Feb 9, 2015 at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote:> On Mon, Feb 9, 2015 at 12:24 PM, Shankar Easwaran <shankare at codeaurora.org > > wrote: > >> Hi, >> >> The round trip passes just tries to load a *complete* object file in >> YAML/Native format back. >> >> The internal state should be the complete object file in native/yaml >> format. >> >> If some state is not recorded and that is really needed in the writer, we >> should add that to the Atom model. >> > > Again, not only saying we should do something, but please elaborate why > you think we should. Otherwise we can't discuss... >The RoundTrip passes was a method to verify the Atom model. When the pass was written / reviewed, this pass was a way to verify that all information passed to the writer was passed through an Atom. I am completely ok to remove the pass as long as there is an alternative with which we can verify. Shankar Easwaran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/4883d0c7/attachment.html>