From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26240 invoked by alias); 6 Mar 2003 01:49:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25921 invoked from network); 6 Mar 2003 01:49:50 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 6 Mar 2003 01:49:50 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18qmPO-0004gP-00; Wed, 05 Mar 2003 21:51:02 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18qkW3-0000GL-00; Wed, 05 Mar 2003 20:49:47 -0500 Date: Thu, 06 Mar 2003 01:49:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: "J. Johnston" , gdb@sources.redhat.com Subject: Re: gcore and nptl threads on linux Message-ID: <20030306014947.GA952@nevyn.them.org> Mail-Followup-To: Andrew Cagney , "J. Johnston" , gdb@sources.redhat.com References: <3E653983.8010005@redhat.com> <20030305005218.GA9222@nevyn.them.org> <3E662E68.7010205@redhat.com> <20030305172511.GB4425@nevyn.them.org> <3E669CA1.2010201@redhat.com> <20030306010428.GA17878@nevyn.them.org> <3E66A811.8030203@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E66A811.8030203@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00114.txt.bz2 On Wed, Mar 05, 2003 at 08:44:49PM -0500, Andrew Cagney wrote: > >On Wed, Mar 05, 2003 at 07:56:01PM -0500, Andrew Cagney wrote: > > > >> > > > >>>>I would think the null_ptid would serve in such a case. > > > >>> > >>> > >>>I guess the issue is that we should be dumping the set of LWPs to the > >>>generated core file, not the set of threads. It seems to me like GDB > >>>should be aware of the list of LWPs, and it shouldn't be hidden in each > >>>individual thread package. > > > >> > >>You mean add them to the `struct thread_info' list? Why not (ignoring > >>technical realities for the moment :-)? > > > > > >Well, I wouldn't do it that way. I haven't really designed this, so > >bear with me if it has some squishy spots. > > > >I think there should be two lists: > > all threads > > all lwps > > I believe in `zero, one, many': > > - lwps > - processes > - threads (as in pthread) > - threads (as in a java interpreter thread) > - tasks (as in ada) Makes sense. > Each has something like: > > - an architecture > - a target > - an owner? Not sure... > >Should the data structures be the same? I don't know. The mapping > >between them would be defined by the thread stratum; its role would be > >to take thread requests, convert them to LWP requests, and pass them > >on. The process stratum would be responsible for managing all of the > >LWPs. > > Things to do today should include throwing out stratum (along with the > bath water). Good luck, it's been on my list for a year and a half or so and every time I try I get scared and find something else to do. > >This has some advantages, I think. Here's one: we would have a logical > >interface for reporting an event from an LWP that doesn't currently > >have a thread. This happens in LinuxThreads, as I've mentioned > >recently. The thread stratum could see that the inferior ptid was just > >an LWP id and pass the request along no questions asked. > > ? That sounds a bit up-side-down, shouldn't events be propogating up - > lwp gets to see them before thread? I disconnected from myself there. Event -> lwp layer -> thread layer; GDB request -> thread layer -> lwp layer. > >Hmm, definitely some loose edges in that one. Should both an LWP and a > >thread have a regcache? Might work. > > Don't forget that a regcache is just a local performance optimization - > a look-a-side buffer. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer