Single stepping an MOV %CR3,%EAX

Just been hunting down a bug in dtrace which would crash on
the following on a i386 (2.6.24) kernel:

$ dtrace -n fbt::native_flush*:
...

Turns out one of the functions will be a "MOV %CR3,%EAX", and when
single stepping, the kernel will step the *next* instruction too.
The way dtrace is coded, we copy the instruction to be stepped to a buffer
(because the original has a 0xcc INT3 as the first byte), but the buffer
is null (0x00) filled. 0x00 isnt a good x86 instruction to randomly
execution, leading to a panic.

The cure seems to be to put a NOP in the copied instruction buffer, and
dtrace is happy to step over the double-instruction and we regain control
and carry on nice.

Strangely, this didnt happen on amd64 (probably because the first instruction
of a probe never corresponded to the equivalent instruction).



Post created by CRiSP v10.0.2a-b5878