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

From: John Kacur
Date: Sat Jan 08 2005 - 00:18:18 EST


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

-
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/