Re: 2.2: TaskID's for CLONE_PID? Proper signal handling?

Andi Kleen (ak@muc.de)
08 Jan 1998 06:08:03 +0100


Peeter Joot <peeter@joot.com> writes:

> >Another thing that needs to be added is a CLONE_TRACE, and propbably
> >a CLONE_PARENT too to allow debugging of multithreaded programs. Funny
> >is that gdb 4.16 already supports it (when it gets a uknown pid from
> >the waitpid() that waits for the debugee it'll automagically add it to
> >its thread tables). Just the kernel doesn't support it yet. I'm not sure
> >if CLONE_TRACE should be folded into CLONE_PID or not. CLONE_PARENT
> >is probably obsolete then.
>
> I don't think that I understand a lot of what you are saying here. I don't
> think any other CLONE_ options are required.
>
> gdb 4.16, as far as I know, only supports thread debugging on specific
> platforms (probably hurd, and a couple other things). For anything else
> platform specific gdb code is needed.

No, that is wrong. Please look at the gdb source. When it receives the
the pid of a new process/thread while it waits for the debugee (wait4())
it'll automagically add it to its internal debugging tables. This code
is enabled per default, not even a recompile is needed :).

-A.