From: Daniel Jacobowitz <drow@mvista.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Snyder <msnyder@redhat.com>,
Roland McGrath <roland@redhat.com>,
gdb@sources.redhat.com
Subject: Re: libthread_db thread handles
Date: Tue, 14 Jan 2003 23:56:00 -0000 [thread overview]
Message-ID: <20030114235709.GA10363@nevyn.them.org> (raw)
In-Reply-To: <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
prev parent reply other threads:[~2003-01-14 23:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20030110204624.GA32002@nevyn.them.org>
[not found] ` <86wulbc29o.fsf@elgar.kettenis.dyndns.org>
[not found] ` <20030113214916.GA18517@nevyn.them.org>
[not found] ` <3E235404.45568034@redhat.com>
[not found] ` <20030114002758.GA30705@nevyn.them.org>
[not found] ` <3E24901B.4841796E@redhat.com>
2003-01-14 22:46 ` Daniel Jacobowitz
2003-01-14 23:01 ` Roland McGrath
2003-01-14 23:07 ` Daniel Jacobowitz
2003-01-14 23:08 ` Ulrich Drepper
2003-01-14 23:20 ` Daniel Jacobowitz
2003-01-14 23:41 ` Ulrich Drepper
2003-01-14 23:47 ` Roland McGrath
2003-01-15 0:16 ` Michael Snyder
2003-01-14 23:56 ` Daniel Jacobowitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030114235709.GA10363@nevyn.them.org \
--to=drow@mvista.com \
--cc=drepper@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=msnyder@redhat.com \
--cc=roland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox