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

[Andi Kleen]

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
-
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/