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

[ccoutant at gmail dot com]

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

Cary Coutant <ccoutant at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ccoutant at gmail dot com

--- Comment #4 from Cary Coutant <ccoutant at gmail dot com> ---
> 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.

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.

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?

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