Re: Does gdb debuginfod download libc etc.?

Simon Marchi via Gdb <[email protected]> writes:

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

This should be handled already in solib_map_sections.  Initially we open
a local file based on the shared library filename, but then we call
core_target_find_mapped_file which looks up the file based on the
filename and a representative address mapped within the shared library,
and returns some data that includes the build-id.

We the compare the build-id for the local file with that obtained from
the core file.  If they don't match we close the local file we initially
opened, and then try to find a suitable file based on the build-id.

Or if there was no local file to open, then we also do the lookup by
build-id path.

Thanks,
Andrew