Re: RFA: gdb/568, messy thread exits

[Michael Snyder <msnyder at redhat dot com>]

Daniel Jacobowitz wrote:
> 
> On Wed, Aug 14, 2002 at 12:00:03AM +0200, Mark Kettenis wrote:
> >    Date: Mon, 12 Aug 2002 12:14:47 -0400
> >    From: Daniel Jacobowitz <drow@mvista.com>
> >
> >    Michael, Mark - what do you think of this patch?  A better explanation
> >    of the patch is at:
> >      http://sources.redhat.com/ml/gdb-patches/2002-07/msg00630.html
> >
> > It's a kludge.  Therefore I'm not inclined to say that this can go in.
> > We should really fix things such that lwp_from_thread isn't called
> > under the circumstances where you're having problems, or we should
> > modify it such that it doesn't have to call td_ta_map_id2thr() under
> > those troublesome circumstances.
> >
> > If we can't come up with such a patch in a timely fashion, we could
> > decide to get this in, but not without a comment saying that it is a
> > kludge.
> 
> Well, let me elaborate.
> 
> lwp_from_thread consults data structures in the inferior, just like the
> rest of thread_db.  As such, I have to consider it... "untrusted" if
> you will.  The inferior crashes unexpectedly - we can't call
> lwp_from_thread any more.  The inferior gets corrupted - we can't call
> lwp_from_thread any more.  As such, I think we need to be at least a
> little more graceful with this function everywhere we touch it (which
> is far too often, if you look at the target traffic dumps).  The same
> goes for any other request we make of thread_db.  So the fixes would
> not be in calling it less, but in allowing it to fail (more)
> gracefully.

You're right, there is a problem -- but this isn't the solution.
It's too simple.


> To be honest, I gave up on this entirely.  We don't support any
> non-one-to-one threads packages via thread-db.c; we've never tested
> with any unless someone's got one up their sleeve that they're not
> talking about. 

I believe the next  major revision of glibc is expected
to include one-to-many thread mapping.  At least it used
to be expected to...


> I dispensed with that part of the abstraction layer
> completely, and got a threads package several times faster, simpler,
> and more reliable (I posted some additional test cases that it passed
> and thread-db.c/lin-lwp.c didn't a few months ago; no one ever
> commented on them).  It's sitting in gdbserver/thread-db.c and
> gdbserver/linux-low.c if you want to look at it.  I believe it'll scale
> to non-one-to-one, and I tried to preserve that in the design, but
> actually supporting all the mapping calls when we don't have any such
> packages just seemed like a bad idea.  It's too complex for me to get
> it right blind.
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer