> But what should happen if I do PTRACE_POKEUSER (MSR_SE = 1)?
> (1) Should it get cleared on the next PTRACE_CONT or PTRACE_SINGLESTEP?
> or
> (2) Should PTRACE_CONT start behaving the same way as PTRACE_SINGLESTEP until
> someone does PTRACE_POKEUSER (MSR_SE = 0)?
We are discussing this upst
On Thu, 20 Mar 2008 01:05:40 +0100, Roland McGrath wrote:
...
> AFAIK no other machine has an unprivileged instruction that can enable its
> hardware single-step flag. So e.g. powerpc's MSR_SE is not truly part of
> the actual user CPU state. However, powerpc does let you set MSR_SE by
> returnin
On Thu, 20 Mar 2008 01:05:40 +0100, Roland McGrath wrote:
> I had not looked into the step-jump-cont-strict case before.
> I think this test is wrong in its expectation.
step-jump-cont itself should be a simple test now (it always PASSes, it FAILed
only on one older i386 utrace kernel).
step-jump
> I think the fix is for GETREGS to clear TF if it was set implicitly though
> SINGLESTEP.
This is the behavior of 2.6.25 (and older utrace kernels).
See TIF_FORCED_TF.
Thanks,
Roland
> The behavior of recent kernels (2.6.25-rcN) and of past utrace kernels for
> a long time is to preserve the "normal" behavior of TF for the program
> itself. That means the TF bit is seen in eflags if user program put it
> there. On x86 this can be done (and some programs do it) with pushf/popf
I had not looked into the step-jump-cont-strict case before.
I think this test is wrong in its expectation.
The behavior of recent kernels (2.6.25-rcN) and of past utrace kernels for
a long time is to preserve the "normal" behavior of TF for the program
itself. That means the TF bit is seen in ef
