Re: Trap flag handling change in 2.6.10-bk5 broke Kylix debugger

From: Linus Torvalds
Date: Tue Feb 14 2006 - 15:50:26 EST




On Tue, 14 Feb 2006, Paulo Marques wrote:
>
> Anyway, using the awesome magical power of blind "hand patching", I tried to
> revert this from the 2.6.16-rc3 kernel, but my powers have let me down this
> time :(
>
> Alas, the current kernel is very different from the 2.6.10 version and I don't
> understand this code enough to be able to modify it. (I did try it anyway,
> without success: the debugger still hung).

It does sound like the Kylix debugger depended very tightly on some very
specific old implementation issue. I don't see quite what it could be (gdb
didn't really care, for example), but yes, semantics _did_ change.

With the new semantics, the process doesn't see that it's being debugged
any more because the TF flag change is now hidden from the signal stack.
That indirectly also means that the debugger itself only sees TF change in
the register state if the process itself set it (not if the TF bit was set
implicitly by the debugger asking for a singlestep event).

The new semantics are really bug-fixes, and actually made it possible to
debug things that weren't really possible to debug before. And you had to
do some pretty strange things for them to matter to the debugger, but
apparently Kylix does exactly that ;(

> Before I start moving in that direction is there someone who can give me an
> hint about what might be happening and suggest patches to test, etc.?

Hmm. You could try variations on the appended patch. Try changing the
"#if 0" to "#if 1" in various combinations, to see which one Kylix seems
to care about.

Linus

---
diff --git a/arch/i386/kernel/signal.c b/arch/i386/kernel/signal.c
index 963616d..8f403bd 100644
--- a/arch/i386/kernel/signal.c
+++ b/arch/i386/kernel/signal.c
@@ -384,6 +384,7 @@ static int setup_frame(int sig, struct k
regs->xss = __USER_DS;
regs->xcs = __USER_CS;

+#if 0
/*
* Clear TF when entering the signal handler, but
* notify any tracer that was single-stepping it.
@@ -393,6 +394,7 @@ static int setup_frame(int sig, struct k
regs->eflags &= ~TF_MASK;
if (test_thread_flag(TIF_SINGLESTEP))
ptrace_notify(SIGTRAP);
+#endif

#if DEBUG_SIG
printk("SIG deliver (%s:%d): sp=%p pc=%p ra=%p\n",
@@ -478,6 +480,7 @@ static int setup_rt_frame(int sig, struc
regs->xss = __USER_DS;
regs->xcs = __USER_CS;

+#if 0
/*
* Clear TF when entering the signal handler, but
* notify any tracer that was single-stepping it.
@@ -487,6 +490,7 @@ static int setup_rt_frame(int sig, struc
regs->eflags &= ~TF_MASK;
if (test_thread_flag(TIF_SINGLESTEP))
ptrace_notify(SIGTRAP);
+#endif

#if DEBUG_SIG
printk("SIG deliver (%s:%d): sp=%p pc=%p ra=%p\n",
@@ -531,6 +535,7 @@ handle_signal(unsigned long sig, siginfo
}
}

+#if 0
/*
* If TF is set due to a debugger (PT_DTRACE), clear the TF flag so
* that register information in the sigcontext is correct.
@@ -540,6 +545,7 @@ handle_signal(unsigned long sig, siginfo
current->ptrace &= ~PT_DTRACE;
regs->eflags &= ~TF_MASK;
}
+#endif

/* Set up the stack frame */
if (ka->sa.sa_flags & SA_SIGINFO)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/