[PATCH] D30699: [ELF] - Stop producing broken output for R_386_GOT32X relocation.

[Rafael Avila de Espindola via llvm-commits]

Awesome. George, please update the change so both relocations are treated the same way.

Cheers,
Rafael

On March 31, 2017 11:22:02 AM EDT, "H.J. Lu" <hjl.tools at gmail.com> wrote:
>On Fri, Mar 31, 2017 at 8:01 AM, Rafael Espíndola
><rafael.espindola at gmail.com> wrote:
>>> [hjl at gnu-6 tmp]$ cat y.s
>>> .text
>>> .globl _start
>>> _start:
>>> cmp %eax, _start at GOT
>>> [hjl at gnu-6 tmp]$ gcc -m32 -c y.s
>>> [hjl at gnu-6 tmp]$ objdump -dwr y.o
>>>
>>> y.o:     file format elf32-i386
>>>
>>>
>>> Disassembly of section .text:
>>>
>>> 00000000 <_start>:
>>>    0: 39 05 00 00 00 00     cmp    %eax,0x0 2: R_386_GOT32 _start
>>> [hjl at gnu-6 tmp]$ ld -m elf_i386 y.o
>>> [hjl at gnu-6 tmp]$ objdump -dw a.out
>>>
>>> a.out:     file format elf32-i386
>>>
>>>
>>> Disassembly of section .text:
>>>
>>> 08048094 <_start>:
>>>  8048094: 39 05 fc 9f 04 08     cmp    %eax,0x8049ffc
>>> [hjl at gnu-6 tmp]$
>>>
>>> In this case, R_386_GOT32 is computed as G + A, not G + A - GOT.
>>
>> OK, the current situation with gas and bfd ld is somewhat amusing.
>Given
>>
>> mov _start at GOT, %eax
>> cmp _start at GOT, %eax
>>
>> assembled with an old gas we get two R_386_GOT32. After linking, the
>result is
>>
>>  8048094:       a1 fc ff ff ff          mov    0xfffffffc,%eax
>>  8048099:       3b 05 fc 9f 04 08       cmp    0x8049ffc,%eax
>>
>> Would it be ok in your opinion then for an implementation to treat
>> R_386_GOT32X as just a relaxable R_386_GOT32 but unlike bfd produce
>> G+A for both the mov and cmp above?
>>
>
>It is OK.
>
>-- 
>H.J.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170331/4095ab0e/attachment.html>