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

Mon Feb 9 12:24:51 PST 2015

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>