Re: CLONE_PTRACE

["Andi Kleen" <ak _at_ suse.de>]

On Sat, Aug 19, 2000 at 03:37:04PM +0200, Mark Kettenis wrote:
>    Date: Sat, 19 Aug 2000 14:32:51 +0200
>    From: "Andi Kleen" <ak _at_ suse.de>
> 
>    On Sat, Aug 19, 2000 at 01:36:07PM +0200, Mark Kettenis wrote:
>    > It would be *really* useful if processes cloned with the CLONE_PTRACE
>    > flag set would behave a bit more as if they had been attached to by
>    > using ptrace (PTRACE_ATTACH, ...) and send a SIGSTOP to the debugger
>    > when they're started.  That allows the debugger to keep track of all
>    > the active threads (as long as the programmer specified the
>    > CLONE_PTRACE flag of course) right from the start.  The attached patch
>    > accomplishes this.  Without it the debugger won't notice a thread
>    > until the first "interesting" event occurs, which might very well be
>    > the cloned process exiting.
> 
>    I once did a simple hack to solve that problem by adding a "VM identifier"
>    to the /proc file system. The identifiers were just the in kernel addresses
>    of the mm_struct. You do a SIGSTOP and then just search /proc for other 
>    processes with the same VM.
> 
> That would certainly be a useful feature, but I think it is completely
> orthogonal to what my patch tries to accomplish.
> 
>    Disadvantages: not atomic for the gourp (but ptrace is never
>    atomic), and fails for other shared resources like signal handlers
>    (probably not a problem for you)
> 
> And it would only work if the cloned processes are still sharing the
> same process group, which ain't necessarily so.

There are no restrictions regarding the process group.

> True, but it is certainly a common case that GDB is attached right
> from the start.  And even the vmid approach would benefit from
> notifications of new threads created after the initial
> attach.  I don't think, constantly monitoring /proc for new threads is
> a viable alternative.

The alternative is to run a system call ptrace and look for clone and 
fork (and optimizing that by adding a syscall trace wakeup filter to the
kernel). It actually works fine, I did that in the past.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/