Re: [RFC] Proposal for ptrace improvements

[Denys Vlasenko]

On Thu, Mar 3, 2011 at 9:22 PM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> On 03/03, Oleg Nesterov wrote:
>>
>> I'll ask the questions later.
>
> Right now I do not see any holes (but I'll try more ;)
>
> One question, to ensure I really understand you. To simplify,
> consider this particular example.
>
> Tracee:
>
>        int main(void)
>        {
>                kill(SIGSTOP, getpid());
>
>                printf("I am running\n");
>
>                for (;;)
>                        ;
>        }
>
> To simplify again, suppose that the debugger attaches when it is
> already stopped, then it does PTRACE_CONT(0).

I think whatever new attach operation we invent needs to provide
a way to know whether attached task is stopped or not.

If debugger wants to say "please continue doing whatever
you were doing before attachment", then, using this information,
debugger can decide whether to do PTRACE_CONT(0) and
sleep on waitpid, or _don't_ do PTRACE_CONT(0) and
sleep on waitpid.

> In this case the tracee remains SIGNAL_STOP_STOPPED but prints
> "I am running" and enters the endless loop.
>
> (the new debugger can do PTRACE_SEIZE after that and "return"
>  it to the stopped state without affecting jctl state).

As far as I can understand the proposal, yes.
Basically, this behavior is intended for gdb to have a way
to implement it's backdoor-ish hack to have stopped tasks
to nevertheless run some code.
(I bet other people will eventually abuse this in horrible ways)


> Now, if SIGCONT comes (from anywhere) it clears SIGNAL_STOP_STOPPED,
> the tracee traps and reports this event to debugger.

And again, I would like to ask you kernel guys to give
userspace a way to distinguish this stop from other possible stops.

IOW: debugger PTRACE_SYSCALL(0)'ed a job control stopped task.
Debugger gets WIFSTOPPED, WSTOPSIG = SIGTRAP.
Debugger wants to know: is it a "syscall entry/exit" stop
or an "end of job control stop" stop?
Preferably without the need to query PTRACE_GETSIGINFO
on every SIGTRAP - that'd slow strace down a lot.

I imagine one way to do it is to #define a PTRACE_EVENT_foo
for "end of job control stop" stop and return it in high byte
of waitpid status, just like other PTRACE_EVENTs are returned today.

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