This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Mon, Aug 6, 2012 at 3:42 PM, Roland McGrath <> 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".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]