On 05-12-07 23:55, ninjaboy wrote:
yes, i understand my fault, now works, but why TF is reseted to 0 when
the trap is "executed" ?
It's not, or not in a one-shot sense at least. TF is cleared before calling
the trap-handler but is set again on return. Clearing it inside the handler
itself is ofcourse fairly useful in avoiding infinite recursion.
It seems TF is cleared in fact not just for the trap-handler but for any
signal-handlers and this, I suppose, is simply due to the fact that you
generally want to single-step through the linear program and not so much
asynchronous signal handlers.
You can though if you use the ptrace interface (which you should be using
for anything serious anyways).
In 2.6.23, it's this bit in arch/i386/kernel/signal.c:setup_frame() or
arch/x86_64/kernel/signal.c:handle_signal():
/*
* Clear TF when entering the signal handler, but
* notify any tracer that was single-stepping it.
* The tracer may want to single-step inside the
* handler too.
*/
regs->eflags &= ~TF_MASK;
if (test_thread_flag(TIF_SINGLESTEP))
ptrace_notify(SIGTRAP);
2.6.24 united the two arches, but I have no 2.6.24-rc tree handy. But, as
that shows, a debugger gets a notify and may then decide it does in fact
want to single-step a signal handler.
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
