[LLVMdev] [lld] Representation of lld::Reference with a fake target

Rui Ueyama ruiu at google.com
Mon Feb 9 12:30:26 PST 2015 

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>

More information about the llvm-dev mailing list