Messages in this thread | | | From | Denys Vlasenko <> | Date | Tue, 1 Mar 2011 23:14:14 +0100 | Subject | Re: [RFC] Proposal for ptrace improvements |
| |
On Tue, Mar 1, 2011 at 8:06 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > On Tue, 01 Mar 2011 16:24:57 +0100, Tejun Heo wrote: >> P4. PTRACE_SEIZE > [...] >> Completion notification is delivered in the usual way via wait(2). If >> the task was in jctl stop, it would report the stop signal with the >> matching siginfo. If the task hits an existing ptrace trap condition, >> the matching SIGTRAP will be reported; otherwise, SIGTRAP will be >> reported with siginfo indicating PTRACE_SEIZE trap. > > This is a change from the Roland's proposed PTRACE_ATTACH_NOSTOP.
As I see it, Tejun's PTRACE_SEIZE looks almost identical to the sequence of PTRACE_ATTACH_NOSTOP ("attach, but don't affect current state of the tracee. In particular, if it runs normally, let it continue to run") plus PTRACE_INTERRUPT ("if tracee isn't stopped yet, stop it with magic SIGTRAP").
There may be reasons to have PTRACE_SEIZE operation split like that. For one, this allows debugger to do PTRACE_CONT, and later issue PTRACE_INTERRUPT to stop the tracee again. PTRACE_INTERRUPT stop may be better for some scenarios where debugger wants to make the stop invisible to the parent, or when debugger wants to stop just one thread of the process.
> Currently it is already a problem that apps did not / do not expect the first > waitpid after PTRACE_ATTACH may not be SIGSTOP.
That's exactly why we want to add a better alternative, which doesn't insert that blasted SIGSTOP.
-- vda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |