This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] i386-dis: fix decoding of reserved "prefetch" encodings
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Roland McGrath <mcgrathr at google dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 7 Aug 2012 10:34:32 -0700
- Subject: Re: [PATCH] i386-dis: fix decoding of reserved "prefetch" encodings
- References: <firstname.lastname@example.org>
On Mon, Aug 6, 2012 at 3:42 PM, Roland McGrath <email@example.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
> 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
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".