Re: [RFC] Proposal for ptrace improvements

[Tejun Heo]

Hello,

On Fri, Mar 04, 2011 at 02:01:04PM +0100, Denys Vlasenko wrote:
> 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.

Definitely.

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

There's no question that it should be distinguishible.  I was still
mostly thinking about siginfo tho.  Is PTRACE_GETSIGINFO such big
deal?  It's a very simple syscall.  It enters kernel, copyout the
structure and returns.  Are you interested in adding GET_SIGINFO call
to the current ptrace and see how much things actually slow down?

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

Maybe but I'm not fully sure yet because I think for debuggers the
group stop status needs to be available for other ptrace traps too, so
it might really not fit there.  I'd like to avoid twisting debugging
API for performance.  As I wrote before, if this actually is a problem
and can't be done cleanly without siginfo, I think a better way would
be using vdso but that's a bit of complexity and would require some
numbers to justify the complexity.

Thanks.

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