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

[Hui Zhu <teawater at gmail dot com>]

On Thu, Apr 23, 2009 at 09:10, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> 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.

Yes, maybe we can give user some warning and suggests in gdb when they
have trouble with multi-thread debug.

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

About your patch, I think let user choice load which libthread_db is
very cool idea.
Why not let they set which file they want to load directly?

For example:
set libthread-db /xxx_dir/libxxx

Let they choice, why not let they choice everything?  :)


Thanks,
Hui