Re: [RFC] Proposal for ptrace improvements

[Denys Vlasenko <vda.linux@googlemail.com>]

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