From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26839 invoked by alias); 12 Mar 2002 16:23:28 -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 26744 invoked from network); 12 Mar 2002 16:23:25 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 Mar 2002 16:23:25 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16kp3j-0006bF-00; Tue, 12 Mar 2002 11:23:31 -0500 Date: Tue, 12 Mar 2002 08:23:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait() Message-ID: <20020312112331.A24963@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <1020311234554.ZM20650@localhost.localdomain> <20020311214703.A462@nevyn.them.org> <1020312031619.ZM21458@localhost.localdomain> <20020311222334.A3178@nevyn.them.org> <1020312075215.ZM22017@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020312075215.ZM22017@localhost.localdomain> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00183.txt.bz2 On Tue, Mar 12, 2002 at 12:52:16AM -0700, Kevin Buettner wrote: > On Mar 11, 10:23pm, Daniel Jacobowitz wrote: > > > On Mon, Mar 11, 2002 at 08:16:19PM -0700, Kevin Buettner wrote: > > > I think that an LWP id cache is only useful so long as all of the > > > threads are stopped. This is because the mappings could change in the > > > course of running the program. So, for this particular case, where > > > the threads are running and we want to wait for one of them to stop, > > > the cache wouldn't be useful to us. > > > > > > Of course, if we have knowledge that a particular thread > > > implementation never changes its mappings or perhaps only changes its > > > mappings for certain threads, we might be able to use such a cache > > > across the stop/start transitions. However, I think that Mark had > > > intended for thread-db.c to be a fairly generic solution that's not > > > wedded to any one particular thread implementation. In particular, it > > > should be possible to use it with an M:N model in which a thread may > > > migrate from one LWP to another. > > > > This implies that part of the caching should be in lin-lwp.c rather > > than in thread-db.c... that knowledge belongs with the lower level > > threading layer. Does that make sense? > > I think I see what you're driving at, though I don't think it belongs > in lin-lwp.c. lin-lwp.c should, I hope, be usable as is by a number > of different thread implementations. Instead, I think what you have > in mind should reside in some sort of policy adjuct to thread-db.c > which understands the kinds of relationships that can exist between > thread ids and lwp ids. If it knows that the thread implementation > uses a 1:1 model as linuxthreads does now, it can use agressive > caching. (By which I mean that the cache is allowed to persist > between stops in the debugger). If it uses a M:N model, it must cache > more conservatively. (I.e, the cache must be invalidated whenever the > inferior is resumed.) I think this code could be reasonably generic > and it shouldn't be too hard to implement. The difficult part will be I like this a lot. > to figure out which kind of thread library you have. After all, if > someone provided a dropin replacement for linuxthreads which > implemented M:N threading, how would you tell the difference? ... great care, and maybe a ``set'' option to override? Unfortunately, IBM's ngpt seems to be mostly drop-in, barring some symbol versioning complexity. We can probably find a way to distinguish... what's worse is that NGPT can build as a libpthread.so, but not a libthread_db.so, so we may have to handle mismatches :( > > We could also, for instance, update the cache via thread event > > reporting... > > If the thread events tell GDB when a thread has migrated from one > LWP to another, then this would work too. Yes, that could probably be arranged. Someday we should talk to a vendor of an M:N threads package and see what we have to work with. I don't know of any offhand besides NGPT. > ... > > But, for the problem at hand (i.e, the bug that my patch is intended > to fix), I think it's important that we first make it work without > caching. As I see it, the cache ought to exist to enhance > performance, not guarantee basic correctness. If we can't make it > work without some sort of caching or enhanced thread event reporting, > we need to understand exactly why first. I agree. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer