Re: CLONE_PTRACE

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

On Sat, Aug 19, 2000 at 08:31:27PM +0200, Mark Kettenis wrote:
>    Date: Sat, 19 Aug 2000 19:40:18 +0200
>    From: "Andi Kleen" <ak _at_ suse.de>
> 
>    On Sat, Aug 19, 2000 at 03:37:04PM +0200, Mark Kettenis wrote:
>    >    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.
>    > 
>    > 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.
> 
> I thought you sent the initial SIGSTOP to the process group, and
> expected it to stop all possible interesting processes before
> searching /proc.  Seems that's not what you were doing.

No, I look through /proc for all processes with the same vmid and ptrace
them all (that's why I said it is not atomic) 

> 
>    > 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.
> 
> The filter is probably pretty essential to get adequate performance.
> I still think that my proposed change is cleaner.

Yours just depends on all programs setting CLONE_PTRACE, which is a bit
if (to make it really useful for the debugger would require a CLONE_NO_PTRACE
and a sysctl, which would be too ugly)

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