Home Original page

[PATCH] i386-dis: fix decoding of reserved "prefetch" encodings

H.J. Lu hjl.tools@gmail.com
Tue Aug 7 17:36:00 GMT 2012 
On Mon, Aug 6, 2012 at 3:42 PM, Roland McGrath <mcgrathr@google.com> wrote:
> When the extra encodings of "prefetch" that the assembler doesn't generate
> are used, the disassembler gets confused and loses track of the instruction
> boundaries.
>
> This fixes it by decoding those forms.  For the AMD variant I used the
> mnemonic "prefetch", because the AMD manual says that the reserved prefetch
> types are treated as synonyms for the basic prefetch type (0), for which
> the mnemonic is "prefetch".  For the Intel variant, I used the
> pseudo-mnemonic "prefetch(bad)", because the Intel manual says that use of
> any but the prescribed types "will lead to unpredictable behavior".
>
> Perhaps it would be better for all these to yield a more informative
> pseudo-mnemonic such as "prefetch(amdresv4)" or "prefetch(intelresv4)".
> I don't have a particular opinion about that.  What I've done here seems
> to be consistent with the way we disassemble other redundant encodings.
>
> This adds a new test case just to exhaustively cover these variants in the
> disassembler, though there are existing test cases that test some instances
> of the prefetch instructions.  There are no 'make check' regressions on
> x86_64-linux-gnu.
>

Those are marked as NOPs in AMD manual and reserved in Intel
manual.  I don't like "prefetch(bad)".  I can live with "nop/reserved".


-- 
H.J.
More information about the Binutils mailing list