From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19077 invoked by alias); 14 Jan 2003 23:56:49 -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 19069 invoked from network); 14 Jan 2003 23:56:46 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 14 Jan 2003 23:56:46 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Ycnr-0001PG-00; Tue, 14 Jan 2003 19:57:16 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18Yavd-000309-00; Tue, 14 Jan 2003 18:57:09 -0500 Date: Tue, 14 Jan 2003 23:56:00 -0000 From: Daniel Jacobowitz To: Ulrich Drepper Cc: Michael Snyder , Roland McGrath , gdb@sources.redhat.com Subject: Re: libthread_db thread handles Message-ID: <20030114235709.GA10363@nevyn.them.org> Mail-Followup-To: Ulrich Drepper , Michael Snyder , Roland McGrath , gdb@sources.redhat.com References: <20030110204624.GA32002@nevyn.them.org> <86wulbc29o.fsf@elgar.kettenis.dyndns.org> <20030113214916.GA18517@nevyn.them.org> <3E235404.45568034@redhat.com> <20030114002758.GA30705@nevyn.them.org> <3E24901B.4841796E@redhat.com> <20030114224641.GA18618@nevyn.them.org> <3E249864.2060600@redhat.com> <20030114232032.GA3774@nevyn.them.org> <3E24A006.4070703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E24A006.4070703@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00250.txt.bz2 On Tue, Jan 14, 2003 at 03:40:54PM -0800, Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel Jacobowitz wrote: > > > To find the state of a thread, we need to first get a thread handle for > > it and only then can we call td_thr_get_info. I'd like to save a copy > > of the td_thrhandle_t when we get the TD_CREATE event, > > The problem is calling the *_iter functions or so? > > If you have the pthread_t value computing the td_thrhandle_t is an > operation which can be performed entirely without the looking at the > inferior. At least in the new implementation. Just call > td_ta_map_id2thr(). This shouldn't add any measurable overhead. > > I would prefer you caching the pthread_t value very much over caching > any opaque data structure. If this means adding a function > td_ta_map_thr2id() I'd have no problems with it. But not even this > should be necessary since for both events, TD_CREATE and TD_DEATH, the > eventdata is the pthread_t value. And this should be a documented > interface. In the old implementation this isn't true; it does involve a memory read. I see that it's only one, though; I thought it was more. We certainly hold on to the pthread_t value already. Maybe this isn't necessary after all - I'll spend some more time working on the caching and see what I need. If map_id2thr does not require a memory read in NPTL that is a further reason not to bother. We don't need thr2id; td_thr_get_info gives it to us. We've been avoiding using TD_DEATH events because they caused a crash in threaded programs using old glibc versions. Mark has suggested that it's time to drop that requirement and just let those people use GDB 5.3. That makes this simpler. The original problem involved a workaround for grossness involving debugging threads after their TD_DEATH event, and it will be much easier if we receive the event. Consider my request withdrawn. I'll get back to you if we need more. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer