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

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Tue, Aug 25, 2015 at 11:01 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 06 Apr 2009 22:39:20 +0200, Paul Pluzhnikov wrote:
>> We have perhaps uncommon setup here, where we have several installed
>> versions of glibc, and need to debug executables which are compiled
>> and linked against them (using -rpath).
>>
>> Currently, GDB will dlopen("libthread_db.so.1", ...), which means that
>> in order debug "non-standard" binary, one has to set LD_LIBRARY_PATH to
>> point to correct libthread_db before invoking GDB, or it will refuse to
>> see threads in the inferior. This is not automatic, and error prone.
>
> Just out of curiosity:
>
> libthread_db should be compatible with any libpthread thanks to:
>
> $ nm /lib64/libpthread.so.0|grep _thread_db_
> 0000003d1b812010 r _thread_db_dtv_dtv
> 0000003d1b812004 r _thread_db_dtv_t_pointer_val
> 0000003d1b81201c r _thread_db_link_map_l_tls_modid
> 0000003d1b8120c4 r _thread_db_list_t_next
> 0000003d1b8120b8 r _thread_db_list_t_prev
> [39 lines total]

I don't understand what above symbols do, but ...

We've had a lot of systems where installed /lib64/libthread_db was
from glibc-2.7, while target binary was using glibc-2.3.6, and I am
99.99% sure that combination didn't work.

Currently we have most systems using glibc-2.19 in both /lib64 and
target, but when transitioning between OS releases (upgrading
desktops) we frequently have system libthread_db being older than
target libc.

Also, fully-static links are used sometimes, and that often presents
its own challenges.


> Do you use non-glibc libthread_db/libpthread (Bionic?) or this _thread_db_*
> compatibility API does not work even for glibc versions?

We do not use non-glibc libthread_db/libpthread.

Cheers,
-- 
Paul Pluzhnikov