diff options
| author | Roland McGrath <roland@redhat.com> | 2004-09-07 17:49:47 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2004-09-07 17:49:47 -0700 |
| commit | 0cc0515ba0065510d98fae9f1e67d6a502599fd6 (patch) | |
| tree | b95c042462eb1098ed55434895f732379f64eedb /include/linux | |
| parent | f5b01e38a19b351d288b78e3929e96be3d347609 (diff) | |
[PATCH] make single-step into signal delivery stop in handler
On x86 and x86-64, setting up to run a signal handler clears the
single-step bit (TF) in the processor flags before starting the handler.
This makes sense when a process is handling its own SIGTRAPs.
But when TF is set because PTRACE_SINGLESTEP was used, and that call
specified a handled signal so the handler setup is happening, it doesn't
make so much sense. When the debugger stops to show you a signal about to
be delivered, and that signal should be handled, and then you do step or
stepi, you expect to see the signal handler code. In fact, the signal
handler runs to completion and then you see the single-step trap at the
resumed code instead of seeing the handler.
This patch changes signal handler setup so that when TF is set and the
thread is under ptrace control, it synthesizes a single-step trap after
setting up the PC and registers to start the handler. This makes that
PTRACE_SINGLESTEP not strictly a "step", since it actually runs no user
instructions at all. But it is definitely what a debugger user wants, so
that single-stepping always stops and shows each and every instruction
before it gets executed.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
