> This change looks extremely bogus.  Why do you think it is appropriate for
> syscall() to turn off the trace bit, when trap() can do it perfectly
> sufficiently, and gets called anyway?

Quite simple. It can't (At least not in the way it tries currently).

(Yes, I know, the answer in the old comment saying that the trace bit would
be restored from the saved PS is by me. It's wrong.)

On syscalls, the kernel is entered by a lcall instruction. This saves only
the pc and the cs, not the flags. Thus, when the first trace trap out of the
kernel mode is caught, the flags register wasn't yet saved.

We could compare the instruction pointer in the trap routine against the
system call entry point and turn it off only when the pc isn't at the first
few instructions, but... we might eventually add other system entry points
which would make modifications to the trap handling code necessary, or we
might change the current system call entry code.

The latter has just happened. In the old version the flags were saved in the
very first instruction in the kernel. This would have needed code like this:

case T_TRCTRAP:
	if (addr == (caddr)Xsyscall)
		return;		/* wait for pushfl */
	if (addr == (caddr)Xsyscall + 1) {
		frame.tf_eflags &= ~PSL_T;
		return;
	}
#if NDDB == 0
	panic("got trace trap in kernel but no debugger in kernel");
#endif

(code courtesy to Bruce (bde)).

But now the entry code first pushes a literal 0 before the flags. This needs
some more code here. IMHO, it would have been rather unlikely for the
modifier of the syscall entry code to have thought about changing the
trace trap handling code. But that's of course open to discussion.
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) +49-228-985800

------------------------------------------------------------------------------