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 bar@GOT, %eax
> >
> > is only supported with the updated i386 psABI, which requires
> > "mov name@GOT, %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 bar@GOT, %eax". The new psABI
supports "movl bar@GOT, %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 bar@GOT, %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 foo@GOT, %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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
