From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sources.redhat.com
Subject: Re: (linux/threads) Interesting side-effect of "auto-solib-add 0"
Date: Wed, 13 Sep 2006 03:45:00 -0000 [thread overview]
Message-ID: <20060913034518.GH24293@adacore.com> (raw)
In-Reply-To: <20060913022113.GA26971@nevyn.them.org>
> Ah, simple: they're not there. Take a look at the ps_* routines in
> proc-service.c. In particular, ps_pglobal_lookup. It's not at all
> surprising that you couldn't find them; this is a very rare library
> interface. The shared library actually has undefined symbols which
> must be satisfied by GDB.
Ah ha, I see! I didn't realize it was using undefined references...
I've been used to seeing callbacks...
> Do you want to stick a comment in linux-thread-db.c somewhere
> suggesting a look over there too?
Absolutely, might be useful to someone else. I'll do that tomorrow.
> The technical alternative, if you want to implement it, would be to
> always load symbols for libpthread. What do you think? We don't even
> really need debugging symbols - just the minimal (ELF) symbol table.
I have been thinking about that, but there were several little factors
that made me reconsider. The one that I didn't like the most was the
fact that the only way I could see to detect the pthread library being
loaded is by looking at its name. It doesn't feel very elegant to have
to search for "/libpthread.so" or somesuch in GDB. I don't know very
well how GNU/Linux distributions are made, but couldn't that library
be named libpthread-1.8.0.so, for instance, making its identification
harder?
At one point, I considered the idea of detecting libpthread.so, and
printing a warning saying that, because auto-solib-add has been
deactivated, thread support hasn't been enabled. But that's almost
no less work than the above, so pointless.
In the end, because I wasn't able to produce any unexpected behavior
except maybe lack of thread support, and given the probable little
number of times this capability is used (I'm guessing, though), it
didn't seem worth the effort.
I do realize, however, that it shouldn't be too much work, though.
I'm open to both alternatives:
1. Enhance GDB
2. Document the limitation (Eli also agreed with the idea)
--
Joel
next prev parent reply other threads:[~2006-09-13 3:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-13 0:27 Joel Brobecker
2006-09-13 0:33 ` Daniel Jacobowitz
2006-09-13 0:47 ` Joel Brobecker
2006-09-13 2:21 ` Daniel Jacobowitz
2006-09-13 3:45 ` Joel Brobecker [this message]
2006-09-13 3:47 ` Daniel Jacobowitz
2006-09-13 3:23 ` Eli Zaretskii
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=20060913034518.GH24293@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb@sources.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