Re: Does gdb debuginfod download libc etc.?

[Simon Marchi via Gdb <gdb@sourceware.org>]

On 2026-03-08 17:04, Paul Smith via Gdb wrote:
> [separate-debug-file] build_id_to_bfd_suffix: enter
>   [separate-debug-file] build_id_to_debug_bfd_1: Trying
> /lib/debug/.build-id/f8/7c1d8cd2118209ef2350b22b187a64d705d6cd...
>   [separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
>   [separate-debug-file] build_id_to_debug_bfd_1: no suitable file found
> [separate-debug-file] build_id_to_bfd_suffix: exit
> debuginfod_find_executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
> server urls "http://debuginfod:8002"
> checking build-id
> checking cache dir /home/pds/.cache/debuginfod_client
> found
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
> d6cd/hdr-executable (bytes=55)
> found
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
> d6cd/executable (fd=14)
> Reading symbols from
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
> d6cd/executable...
> 
> ⚠️ warning: platform-specific solib_create_inferior_hook did not load
> initial shared libraries.
> 
> ⚠️ warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not
> at the expected address (wrong library or version mismatch?)
> 
> ⚠️ warning: Could not load shared library symbols for 9 libraries, e.g.
> /opt/lib64/libicui18n.so.75.
> Use the "info sharedlibrary" command to see the complete listing.
> Do you need "set solib-search-path" or "set sysroot"?
> Reading symbols from /lib64/ld-linux-x86-64.so.2...
> [separate-debug-file] find_separate_debug_file_by_buildid: start:
> looking for separate debug info (build-id) for /lib64/ld-linux-x86-
> 64.so.2
>   [separate-debug-file] build_id_to_bfd_suffix: enter
>     [separate-debug-file] build_id_to_debug_bfd_1: Trying
> /lib/debug/.build-id/8c/fa19934886748ff4603da8aa8fdb0c2402b8cf.debug...
>     [separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
>     [separate-debug-file] build_id_to_debug_bfd_1: no suitable file
> found
>   [separate-debug-file] build_id_to_bfd_suffix: exit
> [separate-debug-file] find_separate_debug_file_by_buildid: end: looking
> for separate debug info (build-id) for /lib64/ld-linux-x86-64.so.2
> debuginfod_find_debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
> server urls "http://debuginfod:8002"
> checking build-id
> checking cache dir /home/pds/.cache/debuginfod_client
> not found No such file or directory (err=-2)
> (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)

I noticed a difference between the first debuginfod call (which
succeeds) and the second one (that fails).  The first one is
debuginfod_find_executable and the second is debuginfod_find_debuginfo.
Could it be important?

Are you able to replicate those queries using the debuginfod-find CLI
tool?

This is equivalent to the first query, I would expect it to work:

  debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6cd

And this is equivalent to the second query, I would expect it to fail:

  debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf

It would then be interesting to see if you are able to fetch the second
one using (assuming debuginfod really has it):

  debuginfo-find executable 8cfa19934886748ff4603da8aa8fdb0c2402b8cf

Here is the documentation from the debuginfod man page for these two
requests:

   /buildid/BUILDID/debuginfo

     If the given buildid is known to the server, this request will
     result in a binary object that contains the customary .*debug_*
     sections.  This may be a split debuginfo file as created by strip,
     or it may be an original unstripped executable.

   /buildid/BUILDID/executable

     If  the  given buildid is known to the server, this request will
     result in a binary object that contains the normal executable
     segments.  This may be a executable stripped by strip, or it may be
     an original unstripped executable.  ET_DYN shared li‐ braries are
     considered to be a type of executable.

I'm thinking that your ld-linux library might not have debug info (the
.debug_* sections), so it might not be returned by the debuginfo
request, but it could be returned by the executable request.  Even if it
does not have debug info, it would still be valuable for GDB to have it.

> I wonder if it has something to do with this:
> 
>> ⚠️ warning: platform-specific solib_create_inferior_hook did not load
>> initial shared libraries.

GDB still ends up listing the shared libs, so it might be red herring.
It is still curious though.  What OS are you on (I want to know which of
the solib-*.c implementations you are using)?

Simon