llvm dev - Feb 2015 - [LLVMdev] [lld] Representation of lld::Reference with a fake target

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><mailto: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><mailto: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><mailto: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><mailto: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<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> --
> Simon Atanasyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/7a7f4d46/attachment.html>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150209/0c8bf19b/attachment.html>

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>