Fix typo in i386 single step changes

Fix an obvious typo in the recent i386 single stepping changes.

I would recommend to redo all the Wine etc. testing that lead to this patch since it probably never worked.

@@ -725,7 +725,7 @@
 		if (tsk->ptrace & PT_DTRACE) {
 			regs->eflags &= ~TF_MASK;
 			tsk->ptrace &= ~PT_DTRACE;
-			if (!tsk->ptrace & PT_DTRACE)
+			if (!(tsk->ptrace & PT_DTRACE))
 				goto clear_TF;
 		}
 	}

Davide also pointed out that the typo was already in the old code. The goto was never executed because neither 0 nor 1 gave true when anded with 2 (PT_DTRACE)

And we need to deliver the signal anyways, otherwise the debugger cannot see it. The early return is definitely wrong.

Also looking at the code more closely the comment above doesn't match what the code does. I fixed that too.

So a better patch is probably:

Fix logic that worked only by accident in ptrace path.

Fix wrong comment.

@@ -706,27 +706,23 @@
 
 	/* Mask out spurious TF errors due to lazy TF clearing */
 	if (condition & DR_STEP) {
-		/*
-		 * The TF error should be masked out only if the current
-		 * process is not traced and if the TRAP flag has been set
-		 * previously by a tracing process (condition detected by
-		 * the PT_DTRACE flag); remember that the i386 TRAP flag
-		 * can be modified by the process itself in user mode,
-		 * allowing programs to debug themselves without the ptrace()
-		 * interface.
+		/* 
+		 * Ignore steps comming from kernel space.
+		 * Apparently they can happen due to lazy TF clearing
+		 * (where exactly? -AK) 
 		 */
 		if ((regs->xcs & 3) == 0)
 			goto clear_TF_reenable;
 
 		/*
 		 * Was the TF flag set by a debugger? If so, clear it now,
-		 * so that register information is correct.
+		 * so that register information is correct and then
+		 * deliver it as signal so that the debugger sees the 
+		 * step.
 		 */
 		if (tsk->ptrace & PT_DTRACE) {
 			regs->eflags &= ~TF_MASK;
 			tsk->ptrace &= ~PT_DTRACE;
-			if (!tsk->ptrace & PT_DTRACE)
-				goto clear_TF;
 		}
 	}
 

@@ -748,7 +744,6 @@
 
 clear_TF_reenable:
 	set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
-clear_TF:
 	regs->eflags &= ~TF_MASK;
 	return;
 }

The comment is slightly stale, but yours perpetuates the staleness, and doesn't fix the first comment which also talks about staleness.

Back when we were really broken with TF handling, we also used to set TF when we started single-stepping, but we never cleared it until we got a stale DR_STEP event. In fact, we could have the debugger detach from the process, and leave TF set. That's not true any more, and I don't think it was true even before the latest changes - the code (and comment) has been stale for quite a while.

So the whole "lazy TF" thing is really incorrect, and these days it's about the user setting TF on its own.

And the _code_ was corrupted too (and working, but only because it could never trigger anyway).

I'll remove it and fix up the comments.

Linus

Yeah, it's supposed to be removed.

It was old (and clearly broken) cut-and-paste for a condition that can't happen any more, namely that "ptrace & PT_TRACED" is not set any more. That "stale ptrace bit set" condition hasn't been valid for a long time, it just never got removed. Oh, well.

Linus

Well, even though it's unlikely it does anything, I tried the later patch and everything is still OK.