From: "H . J . Lu" <hjl@lucon.org>
To: Mark Kettenis <kettenis@science.uva.nl>
Cc: Daniel Jacobowitz <drow@mvista.com>,
Andrew Cagney <ac131313@cygnus.com>,
Kimball Thurston <kimball@sgrail.com>,
gdb@sources.redhat.com
Subject: Re: gdb and dlopen
Date: Wed, 17 Oct 2001 08:29:00 -0000 [thread overview]
Message-ID: <20011017082901.D10021@lucon.org> (raw)
In-Reply-To: <s3i3d4i1fe3.fsf@soliton.wins.uva.nl>
On Wed, Oct 17, 2001 at 04:59:32PM +0200, Mark Kettenis wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
>
> > > thread_db_thread_alive is EXPENSIVE! And we do it on every attempt to
> > > read the child's memory, of which we appear to have several hundred in
> > > a call to current_sos ().
> >
> > (and lwp_from_thread is a little expensive too...)
> >
> > In the case I'm looking at, where I don't need to mess with either
> > breakpoints or multiple threads (:P), I can safely comment out that
> > whole check.
>
> The FIXME on the check is a bit vague, and probably so since I didn't
> exactly understand what was going on when I wrote that bit of code. I
> believe the need for the check arises from the fact that glibc 2.1.3
> is buggy in the sense that TD_DEATH events are unusable. This means
> that we have no clean way to determine whether a thread exited or
> not. Therefore we have to check whether it is still alive.
>
> If we declare glibc 2.1.3 broken, and force people to upgrade to glibc
Why not? We just declare gdb 5.1 only supports thread in glibc 2.2 and
above.
H.J.
next prev parent reply other threads:[~2001-10-17 8:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <y3radyrjqf8.wl@paladin.sgrail.com>
2001-10-16 13:15 ` Daniel Jacobowitz
2001-10-16 18:23 ` Kimball Thurston
[not found] ` <20011016213252.A8694@nevyn.them.org>
2001-10-16 19:03 ` Daniel Jacobowitz
2001-10-16 20:04 ` Kimball Thurston
2001-10-16 20:17 ` Andrew Cagney
2001-10-16 22:08 ` Daniel Jacobowitz
2001-10-16 22:19 ` Daniel Jacobowitz
[not found] ` <y3rzo6qx1ej.wl@paladin.sgrail.com>
2001-10-16 22:52 ` Kimball Thurston
2001-10-17 8:07 ` Mark Kettenis
2001-10-17 8:29 ` H . J . Lu [this message]
2001-10-17 11:09 ` Daniel Jacobowitz
2001-10-17 14:26 ` Mark Kettenis
2001-10-17 14:34 ` Daniel Jacobowitz
2001-10-17 8:54 ` Andrew Cagney
2001-10-17 15:08 ` Kevin Buettner
2001-10-17 15:57 ` Andrew Cagney
2001-10-17 17:05 ` Daniel Jacobowitz
2001-10-17 23:14 ` Andrew Cagney
2001-10-17 8:42 ` Andrew Cagney
2001-10-17 11:15 ` Daniel Jacobowitz
2001-10-17 12:09 ` Kimball Thurston
2001-10-17 12:58 ` Kevin Buettner
2001-11-08 0:22 ` Daniel Jacobowitz
2001-11-08 8:17 ` Kevin Buettner
2001-11-08 9:44 ` Daniel Jacobowitz
2001-11-08 10:49 ` Kevin Buettner
2001-11-08 11:14 ` Daniel Jacobowitz
2001-11-08 16:17 ` Andrew Cagney
2001-10-16 22:25 ` Kimball Thurston
2001-10-16 15:05 ` H . J . Lu
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=20011017082901.D10021@lucon.org \
--to=hjl@lucon.org \
--cc=ac131313@cygnus.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=kettenis@science.uva.nl \
--cc=kimball@sgrail.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