This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: libthread_db thread handles
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: Michael Snyder <msnyder at redhat dot com>, Roland McGrath <roland at redhat dot com>,gdb at sources dot redhat dot com
- Date: Tue, 14 Jan 2003 18:57:09 -0500
- Subject: Re: libthread_db thread handles
- 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>
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