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

[Rafael Espíndola via llvm-commits]

Given the unfortunate but unavoidable fact that the expression of
R_386_GOT32X does depend on where it is used, the proposed change
seems fairly reasonable.

Cheers,
Rafael


On 31 March 2017 at 10:05, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> OK, I think the summary from the llvm point of view is
>
> * MC has to be changed to produce R_386_GOT32X for "mov _start at GOT,
> %eax" regardless of command line options since the current ABI changed
> the meaning of that expression. This tempts me to just drop the
> -relax-relocations option. I will open a bug about this.
>
> * R_386_GOT32X is not just a R_386_GOT32 that can be relaxed. They
> compute different expressions. R_386_GOT32 should stay as always
> computing R_GOT_FROM_END, R_386_GOT32X will compute R_GOT_FROM_END or
> R_GOT depending on where it is used.
>
> Cheers,
> Rafael
>
>
> On 30 March 2017 at 19:12, H.J. Lu <hjl.tools at gmail.com> wrote:
>> On Thu, Mar 30, 2017 at 3:13 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>> On Thu, Mar 30, 2017 at 3:01 PM, Rafael Espíndola
>>> <rafael.espindola at gmail.com> wrote:
>>>> On 30 March 2017 at 17:59, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>>> On Thu, Mar 30, 2017 at 2:52 PM, Rafael Espíndola
>>>>> <rafael.espindola at gmail.com> wrote:
>>>>>> On 30 March 2017 at 17:45, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>>>>> On Thu, Mar 30, 2017 at 2:40 PM, Rafael Espíndola
>>>>>>> <rafael.espindola at gmail.com> wrote:
>>>>>>>>>> 08048074 <_start>:
>>>>>>>>>>  8048074: c7 c0 74 80 04 08     mov    $0x8048074,%eax
>>>>>>>>>>
>>>>>>>>>> as the GOT entry for _start contains the address of _start.
>>>>>>>>>
>>>>>>>>> Even with trunk I get
>>>>>>>>>
>>>>>>>>> 08048094 <_start>:
>>>>>>>>>  8048094:       a1 fc ff ff ff          mov    0xfffffffc,%eax
>>>>>>>>
>>>>>>>> And I still get -4 with the head of the binutils-2_28-branch branch.
>>>>>>>>
>>>>>>>
>>>>>>> The updated i386 psABI requires to encode "mov _start at GOT, %eax" with
>>>>>>> 0x8b opcode with R_386_GOT32X instead of 0xa1 opcode.
>>>>>>
>>>>>> What about files produced by old assemblers?
>>>>>
>>>>> For the older .o files, G + A - GOT is used.
>>>>
>>>> Which is incorrect?
>>>>
>>>> The current ABI also lists  R_386_GOT32 with the same expression as
>>>> R_386_GOT32X. When is a R_386_GOT32 required to be evaluated as G + A?
>>>>
>>>
>>> And it also says 0x8b opcode should be used.  For R_386_GOT32 without
>>> a base register on a1 opcode, it is undefined.
>>>
>>
>> mov foo at GOT, %eax
>> mov %eax, foo at GOT
>>
>> are special.   If
>>
>> mov %eax, foo at GOT (0x89 opcode or 0xa2 opcode)
>>
>> used, program behavior becomes random.
>>
>> mov foo at GOT, %eax  (0xa0 opcode)
>>
>> weren't used in the old programs since old linker will generate G + A - GOT,
>> which makes program behavior random.  The new assembler should always
>> generate 0x8b opcode for
>>
>> mov foo at GOT, %eax
>>
>> with R_386_GOT32X.
>>
>> It is hard to define a reasonable computation for
>>
>> mov foo at GOT, %eax  (0xa0 opcode)
>>
>> with R_386_GOT32 without introducing more linker complexity.
>>
>>
>> --
>> H.J.