From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10481 invoked by alias); 17 Oct 2004 19:19:45 -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 10420 invoked from network); 17 Oct 2004 19:19:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 17 Oct 2004 19:19:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CJGZB-0006Hi-C3; Sun, 17 Oct 2004 15:19:41 -0400 Date: Sun, 17 Oct 2004 19:19:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [rfa] Include the LWP in thread-db's PTIDs Message-ID: <20041017191941.GB23601@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <20041010213630.GA8218@nevyn.them.org> <416AA623.7080304@gnu.org> <200410111940.i9BJeQU2001164@elgar.sibelius.xs4all.nl> <20041012133140.GB32588@nevyn.them.org> <200410132116.i9DLG50x001428@elgar.sibelius.xs4all.nl> <20041013212714.GA4722@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041013212714.GA4722@nevyn.them.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00303.txt.bz2 On Wed, Oct 13, 2004 at 05:27:15PM -0400, Daniel Jacobowitz wrote: > On Wed, Oct 13, 2004 at 11:16:05PM +0200, Mark Kettenis wrote: > > Date: Tue, 12 Oct 2004 09:31:40 -0400 > > From: Daniel Jacobowitz > > > > On Mon, Oct 11, 2004 at 09:40:26PM +0200, Mark Kettenis wrote: > > > > > > I think assuming 1:1 threads is fair enough. But Daniel, if you're > > > going to do that, I'd like to ask you to rename thread-db.c into > > > linux-thread.c or something like that. > > > > How about glibc-thread-db.c? > > > > I'm not sure whether that's appropriate. NPTL is defenitely > > Linux-specific. The Hurd doesn't have a thread_db yet. I suppose > > that if you're going to make some Linux-specific assumptions > > glibc-thread-db.c isn't right. > > I was not planning on making any Linux-specific assumptions in the > thread-db code - just in lin-lwp. I doubt glibc's thread_db > implementation is going to support non-1:1 threading, and that's the > only assumption I am planning on using in what is now thread-db.c. > > But I don't know much about threading for the only active non-Linux > users of glibc (the kBSD projects and the Hurd). Do you think that the > 1:1 assumption is Linux-specific rather than glibc-specific? If so, > linux-thread-db.c would be a better choice indeed, and I can use that. Ping on the renaming question. I think that I should take care of the renaming of this file before I start adding assumptions to it, so I withdraw the patch at the beginning of this thread until that has been taken care of. > > Anyway, I'm wondering if there should be some other method of > > communication between the native and thread strata (as opposed to > > between lin-lwp and thread_db!). I don't much want to use to_wait for > > this, because the assumption in the rest of GDB is that to_wait returns > > when all threads are stopped and I don't want to gratuitously stop all > > threads when we receive a creation event. > > > > But you don't have to return from to_wait upon a creation event. But > > we probably should if the user asks us to report new threads. The > > current way of printing [new thread] messages is a bit broken, since > > GDB doesn't always have control over the terminal. > > Indeed, we don't have to return from to_wait after thread creation. > However, if there are thread strata above us, we want to report the new > thread to them promptly. For instance, the thread-db layer should > always (when in use) sit between lin-lwp and GDB for thread reporting, > so that threads are reported with the correct TID. > > [It's a little more complicated than that, in this case. The TID is > not available quite as early as the LWP is, so we have the LWP without > its corresponding thread. So GDB might have to handle the thread IDs > changing during its lifetime; ew.] I'm still thinking about this bit... -- Daniel Jacobowitz