Re: [PATCH] ptrace(2) single-stepping into signal handlers

Andi Kleen
2005-06-05T11:21:30Z

On Fri, Jun 03, 2005 at 01:21:20PM -0400, John Blackwood wrote:
> 1. Make the default behavior that we single-step to the next instruction
> in the main (non-signal handler) stream of execution, instead of
> single-stepping into the user's signal handler.

I think it is better to not change the default behaviour. You risk
breaking programs and there are much more that use ptrace than just gdb.

>
> 2. Add a new ptrace PTRACE_SETOPTIONS command flag,

I think it would be better to just define a new ptrace singlestep command
with the new semantics instead of adding options.

> - The ptraced process has a pending signal and
> it stops to notify the debugger.
>
> - The debugger then single-steps into the ptraced process's signal handler.
>
> - On the next eventual continue (PTRACE_CONT) command, we run through the
> signal handler, and we stop once again at the next instruction before
> we changed our execution stream and single-stepped into the user's
> signal handler.
>
> - At this point, we can no longer continue the ptraced process
> with a PTRACE_CONT command. Instead, all ptrace(2) PTRACE_CONT calls
> are treated as if we had made a ptrace(2) PTRACE_SINGLESTEP call.

Have you actually seen this in practice?
>
> - We saved off the eflags (with the TF bit set) in setup_sigcontext()
> before we single stepped into the user's signal handler.
>
> - When we exit the user's signal handler via a PTRACE_CONT call,
> we restore the original eflags value (with the TF bit set) in the
> restore_sigcontext() routine. However, at this point, the
> PT_DTRACE flag is no longer set.
>
> - Subsequent ptrace(2) PTRACE_CONT calls will call
> clear_singlestep() to make sure that any single-step state is
> cleared out before we continue the ptrace process.
>
> However, since the PT_DTRACE flag is not set, we do NOT clear
> the TF bit in the eflags register stack location, and we
> instead end up doing a single-step operation.
>
> Also, if we do a PTRACE_SINGLESTEP operation at this point, to
> attempt to get out of this stuck state, the set_singlestep()
> routine will not set the PT_DTRACE flag since the TF flag
> is already set!

Sounds like a bug. Can you submit a change for that separately?

-Andi