Re: minor nit with decoding popf instruction - was Re: ptrace single-stepping change breaks Wine

[John Kacur <jkacur@rogers.com>]

On Fri, 2005-01-07 at 01:48, Linus Torvalds wrote:
> On Thu, 6 Jan 2005, John Kacur wrote:
> > 
> > In order to avoid false positives, I think you should remove the line
> > case 0xf0: case 0xf2: case 0xf3:
> 
> False positives are ok with instructions that trap - if it traps, we won't 
> much care, since the debugger will get notified about that separately (and 
> unambiguously).
> 
True, I never thought of that, however, you still can drop the test,
there's no point continuing if you detected a lock prefix.

> Also:
> 
> > 0xf0 corresponds to the lock prefix which would trigger an invalid
> > opcode exception with a popf instruction.
> > 
> > 0xf2 and 0xf3 correspond to the repeat prefixes and are also not valid
> > with popf
> 
> I don't think either of those are necessarily true on older x86 chips. 
> Nonsensical prefixes used to be silently ignored. Only in later chips has 
> Intel been more strict about them, and given them meanings.
> 
> In fact, I'm pretty sure it's only "lock" that Intel got a lot more
> careful about.  Try it. I'm pretty sure a "rep" prefix is still accepted
> in front of pretty much all instructions. It just doesn't do anything.
> 
> Is it used? Probably not. But people have done some strange things to 
> "mark" instructions (ie for things like run-time exception handling you 
> can "mark" an instruction by prefixing it with a nonsensical "rep" prefix: 
> the CPU won't care, and you can check at trap time whether it was one of 
> your magic instructions.
> 
> Of course, I'd never admit to doing anything that obscure. Never.
> 
> 		Linus

You're right, in practice I've never seen a processor trigger an
exception when it encounters a nonsensical rep prefix, so dropping the
tests for 0xf2 and 0xf3 could potentially miss cases in the unlikely
event that a compiler generated them. Not relevant here, but that
strange technique to mark the instructions would backfire on 128-bit and
64-bit media instructions that use 0xf2 and 0xf3 in the encoding.

John