Re: [PATCH] nptl: Export libthread_db-used symbols under GLIBC_PRIVATE

On 6/20/21 8:38 AM, Simon Marchi via Libc-alpha wrote:
> On 2021-06-17 3:23 p.m., Florian Weimer via Gdb wrote:
>> Kevin, this *almost* gives us the perfect debugging experience with your
>> patched GDB in Fedora 35, according to my preliminary tests.  A build
>> with the patch is running here:
>>
>>   <https://koji.fedoraproject.org/koji/buildinfo?buildID=1773177>
>>
>> However, it seems that GDB still needs pthread_create in the .symtab to
>> trigger loading of libpthread_db.  A fully stripped libc.so.6 without
>> .symtab does not trigger loading in my experiments.  (The other symbols
>> we preserve for valgrind's sake and are immaterial to GDB.)  In other
>> words,
> 
> Stupid question, but: since pthread_create is a function exposed by the
> libc.so shared library, won't there still be an entry for it in .dynsym?

No question is stupid. Thank you for asking.

Yes, there *must* be a .dynsym entry for pthread_create in libc.so.6 in
order for the dynamic loader to bind the reference to the definition.

> And if so, shouldn't GDB see it?

It should. Today gdb is only using the internal lookup_minimal_symbol()
API in order to trigger libthread_db loading, and it's not clear to me
if that will load *all* of the dynamic symbols during gdb startup.

Someone would need to debug the minsyms.c API to see if something isn't
working as expected.

gdb/minsyms.c:

1267    When files contain multiple sources of symbol information, it is
1268    possible for the minimal symbol table to contain many duplicate entries.
1269    As an example, SVR4 systems use ELF formatted object files, which
1270    usually contain at least two different types of symbol tables (a
1271    standard ELF one and a smaller dynamic linking table), as well as
1272    DWARF debugging information for files compiled with -g.

So it sounds like the data is loadable, and mergeable, but it appears that
it's not all there at early startup in gdb.

-- 
Cheers,
Carlos.