Messages in this thread | | | Date | Fri, 4 Mar 2011 09:44:41 +0100 | From | Tejun Heo <> | Subject | Re: [RFC] Proposal for ptrace improvements |
| |
Hey, Oleg.
On Thu, Mar 03, 2011 at 06:34:22PM +0100, Oleg Nesterov wrote: > > P4. PTRACE_SEIZE > > This is the new request. You know, I'd like to discuss the details > later and separately. Actually, I think the user-space developers > should participate and tell what they need. As for me, I certainly > agree that SIGSTOP from PTRACE_ATTACH is very wrong, and it is very > bad that gdb has to send SIGSTOP if it wants to stop the tracee. > IOW, I agree that something like this is needed and useful. In > particular,
While discussing is good, I'd like to keep things slightly more driven. I think, as anything else, there's a balance to hit between discussing and just pushing things forward. We did fair amount of discussion past two+ months and well I think it's about time to push forward.
By now gdb/strace ppl should be aware of what's going on, right? So, if you guys have something on mind w.r.t. kernel behavior, please share, but I won't wait for some discussion elsewhere to reach a conclusion especially because the issues which seem to cause the most amount of delay are not really about what's necessary to achieve the desired functionalities but wildly different wet wild dreams about sexy unicorns.
> > A better way to solve this is simply giving the tracer the capability > > to listen for the end of jctl stop. > > Hmm. I don't understand what "the end of jctl stop" actually means. > > Since you are talking about WCONTINUED below, I guess it means that > the process is not group-stopped any longer, say, SIGCONT comes.
Yeap, I meant emssion of SIGCONT ending the job control stop in effect.
> > What state the tracee is in can be determined by retriving siginfo > > using PTRACE_GETSIGINFO. > > I don't understand this this details right now... But I guess this > doesn't matter right now. > > Either way, debugger should have the ability to know the tracee's > state wrt group-stop. To oversimplify, it should know the state of > SIGNAL_STOP_STOPPED bit. Correct?
Yes, that information should be available via PTRACE_GETSIGINFO.
Thanks.
-- tejun
| |