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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
