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

[Shankar Easwaran]

I am fine with it. I hope you are not planning to remove YAML.

On 2/6/2015 4:54 PM, Rui Ueyama wrote:
> 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
>>
>>
>
>
> _______________________________________________
> 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/20150206/704d1bcc/attachment.html>