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

[Linus Torvalds <torvalds@xxxxxxxx>]

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).

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/