Re: [patch][rfc] Allow GDB to search for the right libthread_db.so.1

[Daniel Jacobowitz <drow@false.org>]

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