Re: [rfa] Include the LWP in thread-db's PTIDs

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Oct 13, 2004 at 11:16:05PM +0200, Mark Kettenis wrote:
>    Date: Tue, 12 Oct 2004 09:31:40 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    On Mon, Oct 11, 2004 at 09:40:26PM +0200, Mark Kettenis wrote:
>    > 
>    > I think assuming 1:1 threads is fair enough.  But Daniel, if you're
>    > going to do that, I'd like to ask you to rename thread-db.c into
>    > linux-thread.c or something like that.
> 
>    How about glibc-thread-db.c?
> 
> I'm not sure whether that's appropriate.  NPTL is defenitely
> Linux-specific.  The Hurd doesn't have a thread_db yet.  I suppose
> that if you're going to make some Linux-specific assumptions
> glibc-thread-db.c isn't right.

I was not planning on making any Linux-specific assumptions in the
thread-db code - just in lin-lwp.  I doubt glibc's thread_db
implementation is going to support non-1:1 threading, and that's the
only assumption I am planning on using in what is now thread-db.c.

But I don't know much about threading for the only active non-Linux
users of glibc (the kBSD projects and the Hurd).  Do you think that the
1:1 assumption is Linux-specific rather than glibc-specific?  If so,
linux-thread-db.c would be a better choice indeed, and I can use that.

>    > Anyway, in that case I think linux-thread.c should be a fairly
>    > lightweight layer around the normal Linux LWP-aware
>    > inf-ptrace.c-derived target vector.  Only use it to provide an LWP <->
>    > TID mapping, and perhaps an initial list of LWPs to attach, but
>    > nothing else.  The normal Linux target vector should in no way be
>    > dependent on it, such that it allows alternative threads strata on top
>    > of it.  Something else just would be a bad design.
> 
>    What I'm wondering is how to handle new threads.  There are two
>    options: have the kernel report them and lin-lwp report them to
>    thread-db, and have thread-db discover them and tell lin-lwp to attach
>    to them.  The former is much nicer but see below...
> 
> Agreed.  If the LWP-layer could discover new LWP's without the help of
> a threads-layer, all possible threads layers would benefit.
> 
>    Anyway, I'm wondering if there should be some other method of
>    communication between the native and thread strata (as opposed to
>    between lin-lwp and thread_db!).  I don't much want to use to_wait for
>    this, because the assumption in the rest of GDB is that to_wait returns
>    when all threads are stopped and I don't want to gratuitously stop all
>    threads when we receive a creation event.
> 
> But you don't have to return from to_wait upon a creation event.  But
> we probably should if the user asks us to report new threads.  The
> current way of printing [new thread] messages is a bit broken, since
> GDB doesn't always have control over the terminal.

Indeed, we don't have to return from to_wait after thread creation. 
However, if there are thread strata above us, we want to report the new
thread to them promptly.  For instance, the thread-db layer should
always (when in use) sit between lin-lwp and GDB for thread reporting,
so that threads are reported with the correct TID.

[It's a little more complicated than that, in this case.  The TID is
not available quite as early as the LWP is, so we have the LWP without
its corresponding thread.  So GDB might have to handle the thread IDs
changing during its lifetime; ew.]

> Thread creation is less critical than thread exit.  It doesn't matter
> if you don't access something that's already there. It does matter if
> you try to access something that's no longer there.  Akthough hitting
> a breakpoint in a thread that we don't know about yet can be a little
> tricky.

More than just tricky - in NPTL it is fatal.  This is one of the few
points where I agree that the threading model is clinically broken.
If a thread that the debugger is not attached to takes a fatal signal,
the thread group will exit.

> It might be a good idea though to clearly distinguish between kernels
> where thread creation is reported correctly and kernels where it
> isn't.

Distinguish in what sense?  Use a different implementation?  We already
test at run-time whether we can expect thread creation events; it's in
linux-nat.c.

-- 
Daniel Jacobowitz