Re: RFA: gdb/568, messy thread exits

[Daniel Jacobowitz <drow@mvista.com>]

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.

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