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

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Wed, Apr 22, 2009 at 10:25 AM, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Apr 20, 2009 at 12:08:54PM -0700, Paul Pluzhnikov wrote:
>
>> 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.

But if we don't have symbols, libthread_db will not work at all
(the way linux libthread_db finds out whether it is compatible
with the inferior: it asks GDB to lookup one of the three symbols
in this patch. If GDB says there is no such symbol, then td_ta_new
returns TD_NOLIBTHREAD).

In fact there was a patch to add a warning if we detect
stripped libpthread.so, as this appears to be a common path
to non-working GDB:
http://sourceware.org/ml/gdb-patches/2009-02/msg00232.html

The patch didn't make it, though.

> 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.

Good point.

uClibc currently uses __linuxthreads_version (and diet-libc
doesn't provide libthread_db at all, AFAICT), but that certainly
isn't guaranteed.

OTOH, uClibc could have named its pthread library libmt.so or
anything else, and we have to make some assumptions about names
anyway, or just not issue warnings at all.

I think warning only for dynamic case is a good compromise. It will
also subsume teawater patch mentioned above.

I'll send updated patch next week when I come back from vacation.

Thanks,
-- 
Paul Pluzhnikov