From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10122 invoked by alias); 27 Aug 2002 01:31:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10113 invoked from network); 27 Aug 2002 01:31:59 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 27 Aug 2002 01:31:59 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id SAA09963; Mon, 26 Aug 2002 18:25:02 -0700 (PDT) Message-ID: <3D6AD68B.B6018428@redhat.com> Date: Mon, 26 Aug 2002 18:33:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: RFA: gdb/568, messy thread exits References: <20020731163910.GA5622@nevyn.them.org> <20020812161447.GA770@nevyn.them.org> <200208132200.g7DM03vH034786@elgar.kettenis.dyndns.org> <20020813221350.GA14555@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00884.txt.bz2 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 > > > > 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