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

[Rui Ueyama]

Can we remove Native format support? I'd like to get input from anyone who
wants to keep the current Native format in LLD.

On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

> The only way currently is to create a new reference, unless we can think
> of adding some target specific metadata information in the Atom model.
>
> This has come up over and over again, we need something in the Atom model
> to store information that is target specific.
>
> Shankar Easwaran
>
>
> On 2/5/2015 2:22 PM, Simon Atanasyan 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.
>>
>>
>
> --
> 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/20150206/1e3d7aa0/attachment.html>