Re: Does gdb debuginfod download libc etc.?

On 3/9/26 9:57 AM, Paul Smith wrote:
> 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:

Ah ok, I didn't catch that from your output, sorry.

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

I would add a printf in core_target::build_file_mappings to print the
mapped files and their (if present) build-ids.

And then put a breakpoint or printf in solib_bfd_open, to see when GDB
tries to open the files for the solibs.  It might be that we blindly
open the files from the host, and we could add some build-id checks to
avoid that (and ask debuginfod instead).

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

Yeah sorry, it was late.

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

It would be useful to add debug prints to corelow.c, where it reads the
mappings, and then in solib-svr4.c, where it tries to open the solibs.
I am of the opinion that if adding some debug prints helps you
troubleshoot a problem, then it is worth adding these debug prints
upstream, since they could help somebody else (or even you) in the
future.

Simon