Hi, On Tue, Mar 15, 2011 at 08:33:39AM +0100, Tejun Heo wrote: [...] > The second one is the job control stop. If not for ptrace, the task > would stop in the 'stopped' state and would respond to SIGCONT and > SIGKILL. Under ptrace, well, it first enters the 'stopped' state but > gets moved into 'traced' (debug trap) state by ptrace request. This > is changing and the tracee will enter 'traced' state directly. > > So, the stop is a debug trap but it is implementing the job control > stop and kernel will add mechanism for strace to notice that job > control stop has finished and resume the tracee accordingly, so for > strace's purpose, I think it would be more precies to report it as job > control stop, which strace currently overrides unconditionally (as it > doesn't have any other option).
I've skimmed through that lengthy lkml thread to get the idea how this ptrace interaction with job control is going to be changed. My main user space concern is that if strace will have to *not* resume tracee with PTRACE_SYSCALL upon each CLD_STOPPED/CLD_CONTINUED notification when running on newer kernels, and will have to continue resuming on older kernels, then strace needs a simple and reliable runtime method to find out whether that particular kernel needs resuming after receiving job control notifications. -- ldv
pgpDuMS6ut7Ve.pgp
Description: PGP signature
------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
_______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
