public inbox for
 help / color / mirror / Atom feed
From: Carlos O'Donell <>
To: Simon Marchi <>,
	Florian Weimer <>,
Subject: Re: [PATCH] nptl: Export libthread_db-used symbols under GLIBC_PRIVATE
Date: Sun, 27 Jun 2021 18:25:56 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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:
>>   <>
>> However, it seems that GDB still needs pthread_create in the .symtab to
>> trigger loading of libpthread_db.  A fully stripped 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
> 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 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.


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.


  reply	other threads:[~2021-06-27 22:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 19:23 Florian Weimer
2021-06-20 12:38 ` Simon Marchi
2021-06-27 22:25   ` Carlos O'Donell [this message]
2021-06-29 14:20     ` Simon Marchi
2021-06-29 14:24       ` Florian Weimer
2021-06-28  2:10 ` Carlos O'Donell
2021-06-28  8:34   ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).