[SCM] strace branch, master, updated. v4.5.20-103-g7b6847b

[Dmitry V. Levin]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110315/79b4a367/attachment.bin>