[Bug gold/21285] R_386_GOT32 for baseless case looks implemented incorrectly.

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21285

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Cary Coutant from comment #4)
> > movl address@hidden, %eax
> > 
> > is only supported with the updated i386 psABI, which requires
> > "mov address@hidden, %eax must be encoded with opcode 0x8b, not 0xa0,
> > to allow linker optimization."
> 
> How does this answer my question about distinguishing between the two
> instructions? Right now, gold is treating the 0xa1 as a modrm byte, and
> taking that as an indication that it's a mov instruction with indexing,
> without checking for the 0x8b opcode.

The old psABI doesn't support "movl address@hidden, %eax".  The new psABI
supports "movl address@hidden, %eax", which must be encoded with opcode 0x8b.
The behavior of "a1 00 00 00 00" is undefined.

> But even checking for the 0x8b isn't foolproof, given the instruction
> sequence I proposed. The only way to distinguish is to be more particular
> about what we accept as a modrm byte. We'd have to rule out 0xa1 as a valid
> modrm byte at the very least, so we can take that as the opcode and decline
> to optimize the instruction. If we see anything other than 0xa1, then we can
> treat it as a modrm byte, then go back to the previous byte and check for a
> 0x8b opcode.

In the case of "movl address@hidden, %eax", it isn't an optimization.  Linker
can't subtract the GOT address.  Otherwise, the program will crash.

> Is that reasonable? Should we be even more particular about what we take as
> an acceptable modrm byte for the 0x8b form?
> 
> Side question: How do you force the assembler to generate the "0x8b 0x05
> ..." form?

The assembler skips opcode 0xa0 for GOT32 relocation:

     /* Force 0x8b encoding for "mov address@hidden, %eax".  */
      if (i.reloc[0] == BFD_RELOC_386_GOT32 && t->base_opcode == 0xa0) 
        continue;

-- 
You are receiving this mail because:
You are on the CC list for the bug.