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

[Nick Kledzik]

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