Re: RFA: gdb/568, messy thread exits

Michael Snyder
2002-08-27T01:31:59Z

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