[PATCH] D21215: [docs] Update AMDGPU relocation information

[Rafael Espíndola via llvm-commits]

On 11 June 2016 at 15:05, Tye, Tony <Tony.Tye at amd.com> wrote:
> Hi Rafeal,
> Can you explain a bit more what you mean by "*assumes* the value is 32 bits
> and the linker errors if it is not”.  My understanding was that the
> relocation record explicitly “defines” what size of result it is producing
> and that is what the “Field” column specified.

It defines that the value *must* fit in that field. It is possible to
write cases where it does not and the linker produces an error.

For example, try linking the attached two files. ld.bfd prints


 relocation truncated to fit: R_X86_64_32 against symbol `foo' defined
in *ABS* section in t.so

lld prints

relocation R_X86_64_32 out of range

(yes, we need a better error message).

If there was such a thing as R_X86_64_LO32, it would just write the
low 32 bits of the value and not produce an error.

>
> But it sounds like you are describing that the linker performs the
> relocation expression at infinite precision (which effectively means 64 bit
> precision since that is the address size for the architecture) and then
> checks that the value will fit in the size of the destination defined by
> “Field”. If that is the case how does the linker handle whether the value is
> signed or unsigned? For example, the PC relative relocations can produce
> negative values, meaning that the top bits (namely the bits above the bits
> specified by Field) can either be all 1s or all 0s. Does the linker consider
> the value “in range” provided the top bits are either all 1s or all 0s, and
> out of range otherwise?

The linker knows if the relocation is signed or unsigned.


> A similar question exists for the loader. Does the loader give an error if a
> relocation is out of range by the above definition? For example, if a
> location has a r_x86_32 relocation that the linker checked as being in range
> based on the preferred ELF load address, but due to not being able to be
> loaded at its preferred ELF load address the value becomes out of range,
> will the loader give an error?

Not sure if they handle it. I know that lld refuses to create a
dynamic relocation that might not be in rang during runtime.

> That would imply the relocations should be:
>
>   =====================  =====  ==========  =============
>   Relocation type        Value  Field       Calculation
>   =====================  =====  ==========  =============
>   ``R_AMDGPU_NONE``      0      ``none``    ``none``
>   ``R_AMDGPU_ABS32_LO``  1      ``word32``  (S + A) & 0xFFFFFFFF
>   ``R_AMDGPU_ABS32_HI``  2      ``word32``  (S + A) >> 32
>   ``R_AMDGPU_ABS64``     3      ``word64``  S + A
>   ``R_AMDGPU_REL32``     4      ``word32``  S + A - P
>   ``R_AMDGPU_REL64``     5      ``word64``  S + A - P
>   ``R_AMDGPU_ABS32``     6      ``word32``  S + A
>   =====================  =====  ==========  =============

That LGTM.

> For DWARF, what relocations are used in relocatable object files (since they
> are eliminated in executable and shared library object files since they only
> reference symbols in non-allocated sections)? Are they only using
> R_AMDGPU_REL64 and/or R_AMDGPU_REL32?

I think there is some flexibility in dwarf to say if a rel or abs
relocation is used, but I am not sure.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.s
Type: application/octet-stream
Size: 38 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/877d6aba/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.s
Type: application/octet-stream
Size: 55 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/877d6aba/attachment-0001.obj>