From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1656 invoked by alias); 13 Aug 2002 22:13:31 -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 1648 invoked from network); 13 Aug 2002 22:13:31 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 13 Aug 2002 22:13:31 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17ejuu-0000pY-00; Tue, 13 Aug 2002 17:13:32 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17ejvC-0003r6-00; Tue, 13 Aug 2002 18:13:50 -0400 Date: Tue, 13 Aug 2002 15:13:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, msnyder@redhat.com Subject: Re: RFA: gdb/568, messy thread exits Message-ID: <20020813221350.GA14555@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com, msnyder@redhat.com References: <20020731163910.GA5622@nevyn.them.org> <20020812161447.GA770@nevyn.them.org> <200208132200.g7DM03vH034786@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208132200.g7DM03vH034786@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00330.txt.bz2 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. 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