This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch][rfc] Allow GDB to search for the right libthread_db.so.1
On Mon, Apr 20, 2009 at 12:08:54PM -0700, Paul Pluzhnikov wrote:
> Previously, dlopen was performed at initialization time, and then
> thread_db_ops was pushed when (and only when) td_ta_new returned TD_OK
> (checked on attach, and on every new solib).
>
> If td_ta_new returned TD_NOLIBTHREAD, we assumed that there are no threads
> at all (at least not yet), and any other error produced a warning.
>
> One example where this fails: static LinuxThreads exe on NPTL system:
> td_ta_new returns TD_NOLIBTHREAD (which is semi-correct -- no NPTL
> libpthread), so no warning is issued; but then GDB doesn't work :-(
>
> The symbol lookup is there in the new code to firmly establish a point
> where threads are known to be present, so we can issue correct warning if
> at that point no working libthread_db can be found.
... if we have symbols.
> I don't see how to establish that "threads are present" point without
> symbol lookup, nor how to keep the proper warning if we don't know for
> sure whether they are.
If you want to generate a warning when there are threads - not just
threads, but also a thread library - and no matching libthread_db,
then I suppose this is the only way.
Personally, I'd rather ditch the warning for static binaries. Check
the shared library list for libpthread if all available libthread_db's
have failed, and if there is one, warn then. Any thoughts on that?
Otherwise, I won't object to what you've got. I am just generally
dissatisfied with hard-coding a list of symbols from the
implementation. e.g. uClibc could legitimately use different names.
--
Daniel Jacobowitz
CodeSourcery