[x32] Allow R_X86_64_64

Fri Aug 12 19:59:00 GMT 2011

On Fri, Aug 12, 2011 at 10:53 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Aug 12, 2011 at 8:52 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>> On 12.08.11 at 16:47, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>> On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>> On 12.08.11 at 16:02, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>> On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>>>> On 12.08.11 at 15:22, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>>>> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>>>>>> On 12.08.11 at 14:09, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>>>>>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>>>>>>>> On 12.08.11 at 06:37, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>>>>>>>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It turns out that x32 needs R_X86_64_64.  One major reason is
>>>>>>>>>>>>> the displacement range of x32 is -2G to +2G.  It isn't a problem
>>>>>>>>>>>>> for compiler since only small model is required for x32.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, to address 0 to 4G directly in assembly code, we have
>>>>>>>>>>>>> to use R_X86_64_64 with movabs.  I am checking the follow patch
>>>>>>>>>>>>> into x32 psABI to allow R_X86_64_64.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> X32  Linker should treats R_X86_64_64 as R_X86_64_32
>>>>>>>>>>>> zero-extended to 64bit for output.  I will update x32 psABI with
>>>>>>>>>>>
>>>>>>>>>>> I'm sorry to say that, but the situation about x32 seems to be
>>>>>>>>>>> getting worse with each change you do, every time again
>>>>>>>>>>> revolving around mixing up ABI specification and a particular
>>>>>>>>>>> implementation thereof.
>>>>>>>>>>>
>>>>>>>>>>> Here, if you need something zero-extended (though I can't see
>>>>>>>>>>> why you would), then you should use a new relocation type. As
>>>>>>>>>>> pointed out before, there are valid possible uses of R_X86_64_64
>>>>>>>>>>> that would require the semantics of x86-64.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When does x32 need the semantics of x86-64 for R_X86_64_64?
>>>>>>>>>
>>>>>>>>> When referencing an assembler or linker defined constant that
>>>>>>>>> exceeds 32-bit in width. Given that this is a 64-bit architecture
>>>>>>>>> with 32-bit addresses, at least I would expect such to work.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, it should work just fine for x32 by zero-extending 32bit
>>>>>>>> address to 64bit.
>>>>>>>
>>>>>>> For a constant that has more than 32 significant bits???
>>>>>>>
>>>>>>
>>>>>> Can you give me an example in assembly code?
>>>>>
>>>>> Something like
>>>>>
>>>>>        .equ    sym, 0x1234567890
>>>>>        .global sym
>>>>>
>>>>
>>>> "sym" is truncated to 32bit:
>>>
>>> Yes, because of your tying of the ABI to ELF32.
>>
>> X32 uses ELF32 and won't change.
>>
>>>> Symbol table '.symtab' contains 5 entries:
>>>>    Num:    Value  Size Type    Bind   Vis      Ndx Name
>>>>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
>>>>      1: 00000000     0 SECTION LOCAL  DEFAULT    1
>>>>      2: 00000000     0 SECTION LOCAL  DEFAULT    2
>>>>      3: 00000000     0 SECTION LOCAL  DEFAULT    3
>>>>      4: 34567890     0 NOTYPE  GLOBAL DEFAULT  ABS sym
>>>>
>>>> However, one can write
>>>>
>>>> .quad main + 0x8000000
>>>
>>> And I suppose that wouldn't work either with your R_X86_64_64
>>> implied zero-extension...
>>>
>>
>
> I will add R_X86_64_64 support to x32 dynamic linker.  I will
> also add R_X86_64_RELATIVE64 to x32 dynamic linker.
>
> For R_X86_64_64 relocation, if addend is 0, linker will
> turn it to R_X86_64_32 and zero-extends it to 64bit. Otherwise,
> linker will generate R_X86_64_RELATIVE64 if it is a relocation
> against a local symbol or keep R_X86_64_64 for relocations
> against external symbols. We need R_X86_64_RELATIVE64
> since R_X86_64_RELATIVE only updates 32bit destination.
>
>
> --
> H.J.
> ---
> diff --git a/object-files.tex b/object-files.tex
> index 7f0fd14..d2be264 100644
> --- a/object-files.tex
> +++ b/object-files.tex
> @@ -483,10 +483,13 @@ or \texttt{Elf32_Rel} relocation.
>       \texttt{R_X86_64_TLSDESC_CALL} & 35 & none &  \\
>       \texttt{R_X86_64_TLSDESC} & 36 & \textit{word64}$\times 2$ & \\
>       \texttt{R_X86_64_IRELATIVE} & 37 & \textit{wordclass} &
> \texttt{indirect (B + A)}\\
> +      \texttt{R_X86_64_RELATIVE64} $^{\dagger\dagger}$ & 38 &
> \textit{word64} & \texttt{B + A} \\
>  %      \texttt{R_X86_64_GOT64} & 16 & \textit{word64} & \texttt{G + A} \\
>  %      \texttt{R_X86_64_PLT64} & 17 & \textit{word64} & \texttt{L + A - P} \\
>      \cline{1-4}
>     \multicolumn{3}{l}{\small $^\dagger$ This relocation is used only
> for LP64.}\\
> +    \multicolumn{3}{l}{\small $^{\dagger\dagger}$ This relocation only
> +    appears in X32 executable files or shared objects.}\\
>     \end{tabular}
>   \end{center}
>  \Hrule
>

I checked the enclosed linker change. I also enclosed the glibc change
to handle R_X86_64_RELATIVE64 and R_X86_64_64 for x32.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-pr13082-1.patch
Type: text/x-diff
Size: 13623 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20110812/6113e212/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libc-x32-R_X86_64_64-1.patch
Type: text/x-diff
Size: 2086 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20110812/6113e212/attachment-0001.bin>