This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libthread_db thread handles


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]