From: Daniel Jacobowitz <drow@false.org>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb-patches@sources.redhat.com, msnyder@redhat.com
Subject: Re: [rfa] Include the LWP in thread-db's PTIDs
Date: Tue, 12 Oct 2004 13:26:00 -0000 [thread overview]
Message-ID: <20041012132618.GA32588@nevyn.them.org> (raw)
In-Reply-To: <416AD0D0.4010807@gnu.org>
On Mon, Oct 11, 2004 at 02:28:32PM -0400, Andrew Cagney wrote:
> >Also, it was an approved patch. Michael responded at the end of the
> >thread saying that he agreed it was the right thing not to use
> >thread_db on core files. Yes, there was a lot of disagreement before
> >that; but before the patch was committed the thread-db.c maintainer
> >agreed that we should not to use thread_db in this case. I think I'm
> >justified in saying that "we" have decided this.
>
> But here on this technical matter I'm not.
>
> The discussion starts here (there's a bit in the next month):
> http://sources.redhat.com/ml/gdb-patches/2001-12/msg00345.html
> please read it.
Yes, I read that.
> Given that this was "hard" Michael approved the change (a sound
> technical decision).
>
> Just like on Solaris and consistent with the original thread, the
> user-level thread library should be loaded over the core file as only by
> doing that can user-level thread information be displayed.
Actually, Michael didn't explain why he changed his mind - he just
eventually agreed. Since he's still right here we could ask him :-)
but let's just move on.
> If this makes cross debugging "iffy", fix the bugs, don't cripple GDB
> for it's native users.
Some thinking about your messages has persuaded me that you're right
that we should support thread-db as a separate stratum and support
using it for core files (although I will remain opposed to doing it by
default unless someone adds a robust do-this-image-and-library-match
check - hmm, maybe it's OK if libc is found from the system location
instead of via solib-search-path and solib-absolute-prefix?).
However, please stop calling this a "crippling" issue. Can you even
list the visible changes that using thread-db would cause over just
using corelow's LWP support? As far as I know there are two:
- Thread IDs would not be displayed. Since these are pointer-sized
numbers internal to the NPTL implementation, that's not much of a
loss.
- TLS data may not work, because we currently use thread_db to find
the thread's TLS base. This could be pretty easily fixed by using
a gdbarch mechanism to return the architecture's TLS base and an
xfer_partial gdbarch hook to query native or remote targets for the
value.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-10-12 13:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-10 21:36 Daniel Jacobowitz
2004-10-11 15:29 ` Andrew Cagney
2004-10-11 15:38 ` Daniel Jacobowitz
2004-10-11 15:55 ` Joel Brobecker
2004-10-11 16:17 ` Andrew Cagney
2004-10-11 17:12 ` Daniel Jacobowitz
2004-10-11 18:29 ` Andrew Cagney
2004-10-12 13:26 ` Daniel Jacobowitz [this message]
2004-10-11 19:40 ` Mark Kettenis
2004-10-12 13:31 ` Daniel Jacobowitz
2004-10-13 21:16 ` Mark Kettenis
2004-10-13 21:27 ` Daniel Jacobowitz
2004-10-17 19:19 ` Daniel Jacobowitz
2004-10-13 21:37 ` Paul Gilliam
2004-11-14 19:17 ` Daniel Jacobowitz
2004-12-02 21:16 ` Michael Snyder
2004-12-08 16:14 ` Daniel Jacobowitz
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=20041012132618.GA32588@nevyn.them.org \
--to=drow@false.org \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@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