> 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.
> (If the program set TF itself, then it wanted to run its own SIGTRAP
> handler.)
BTW, there's a bug in current ptrace in this area. It hits you if you are
multiplexing multiple threads onto a single host thread and you are
PTRACE_SINGLESTEPping one and switch away from it. You GETREGS to save its
state, and SETREGS to put the state back when it's ready to run again.
However, GETREGS gave you an eflags with TF set, so you SETREGS an eflags
with TF. At this point, TF is now "owned by you" even though you never
really touched it and the thread single-steps until you explicitly clear TF.
I think the fix is for GETREGS to clear TF if it was set implicitly though
SINGLESTEP.
Jeff
