[lkml]   [2005]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: minor nit with decoding popf instruction - was Re: ptrace single-stepping change breaks Wine
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.038 / U:3.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site