Re: Does gdb debuginfod download libc etc.?

[Paul Smith via Gdb <gdb@sourceware.org>]

On Sun, 2026-03-08 at 22:32 -0400, Simon Marchi wrote:
> 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?

I think this is not an issue.

> 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

This is the build ID for my program, and this exists and is downloaded
properly.

> And this is equivalent to the second query, I would expect it to
> fail:
> 
>   debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf

This is the build ID for the debuginfo for my local system's runtime
linker /lib64/ld-linux-x86-64.so.2:

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

This doesn't exist in my debuginfod server.  It might be nice to have
debuginfo for the runtime linker, but I've never had it for any of my
debugging sessions, because users very rarely install it on their
systems, and it's not been a problem.

Even if I wanted the debuginfo for the runtime linker, things have
already gone awry here because GDB is loading my LOCAL SYSTEM'S runtime
linker, when instead it should have downloaded the core file's runtime
linker which is a different file with a different build ID.

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

The reason I suggest this might be related is that it seems to me that
once we reach this point, GDB has already started to do the wrong
thing.  For example as above, it's use the local system's ld-linux.so
rather than downloading the core file's ld-linux.so.

I would expect that I would see requests to the debuginfod server for
the shared libraries, including the runtime linker itself, but I don't
see any of that.  It only tries to find the executable and the
debuginfo file for the local system's runtime linker, and it never
tries to find anything else.

It would be interesting if Arsen can repeat his (successful)
experiment, setting the DEBUGINFOD_VERBOSE=9 environment variable
first, so we can see where in the processing of GDB startup we should
expect to be seeing debuginfod requests.

> What OS are you on (I want to know which of the solib-*.c
> implementations you are using)?

I'm not sure what you mean by "OS" here; I'm on GNU/Linux x86-64 (as
can be seen from the name of my runtime linker :)).  If you mean the
distribution, my local host is Ubuntu 22.04 LTS and the core file was
generated on, I believe, Red Hat EL 9.

I have built GDB from source, so I'm happy to add any debugging info or
run GDB itself inside GDB, if someone can point me to likely places to
look.

Thanks Simon!