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

[Rui Ueyama via llvm-commits]

But how do you know whether a R_386_GOT32 has a base register or not by
looking at the location where a relocation is applied? IIUC, your old spec
doesn't impose any restrictions on where you can use R_386_GOT32, so you
can use that type of relocation anywhere. Even if it the location where a
R_386_GOT32 looks like a 386 instruction, that could still be some other
kind of data.

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.
>
>
> --
> H.J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170330/ff616948/attachment.html>