summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorRoland McGrath <roland@redhat.com>2004-09-07 17:49:47 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2004-09-07 17:49:47 -0700
commit0cc0515ba0065510d98fae9f1e67d6a502599fd6 (patch)
treeb95c042462eb1098ed55434895f732379f64eedb /include/linux
parentf5b01e38a19b351d288b78e3929e96be3d347609 (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