Re: Does gdb debuginfod download libc etc.?

Paul Smith via Gdb <[email protected]> writes:

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

To me, this is the biggest clue to what's going on here.  I think GDB is
failing to find the build-ids within the core file for some reason.

Without a build-id all GDB has to operate on is the name of the shared
library.  If your local shared library has the same name then GDB will
try to load that, and if the local file has no debug information, GDB
will request the associated debug information from debuginfod.  Which is
what appears to happen here.

If I copy a core file from one of my machines to a totally different OS
version VM, and then try to load it into GDB, GDB finds the build-id and
refuses to load the local shared library.

Given that elf utils manages to read the build-ids from the core file
then I'm not sure what the problem is, but it feels like it must be a
GDB issue. 

Unfortunately, there's no debug flag which reports on GDB as it parses
the build-ids from the core file.  But the patch below which applies to
gdb-17-branch adds a new 'set debug core-load on' command, with this you
should be able to:

  (gdb) set debug core-load on 
  (gdb) core-file ~/core.54313 
  [core-load] build_file_mappings: enter
    [core-load] operator(): start = 0x400000, end = 0x407000, filename = /some/program, build-id = a004xxxx178xxxx78xxxx6c6cxxxx800df88xxxx
    [core-load] operator(): start = 0x407000, end = 0x41e000, filename = /some/program, build-id = NONE
    [core-load] operator(): start = 0x41e000, end = 0x427000, filename = /some/program, build-id = NONE
    [core-load] operator(): start = 0x428000, end = 0x429000, filename = /some/program, build-id = NONE

You get one line like the above for each segment mapped from a core file
into the memory image, so you should expect to see most filenames
repeated multiple times.  However, only one line for a given filename
will have a build-id associated with it, this is the segment that also
contains the build-id.  If *no* lines for a given filename have a
build-id, then GDB didn't find a build-id for that filename.

If you were willing to apply this patch, rebuild GDB, and run this test
then this will split the problem space in half, is the problem GDB
reading the build-id from the core file, or is the problem GDB not using
the build-id it has to lookup the files.

Thanks,
Andrew

---

diff --git i/gdb/corelow.c w/gdb/corelow.c
index 29eafe8bdfd..95dd837e06e 100644
--- i/gdb/corelow.c
+++ w/gdb/corelow.c
@@ -58,6 +58,29 @@
 #define O_LARGEFILE 0
 #endif
 
+/* When true emit 'core-load' debug messages.  */
+
+static bool debug_core_load = false;
+
+/* Handle 'show debug core-load' command.  */
+
+static void
+show_core_load_debug (struct ui_file *file, int from_tty,
+		      struct cmd_list_element *c, const char *value)
+{
+  gdb_printf (file, _("Core-load debugging is %s.\n"), value);
+}
+
+/* Print a "core-load" debug statement.  */
+
+#define core_load_debug_printf(fmt, ...) \
+  debug_prefixed_printf_cond (debug_core_load, "core-load", fmt, ##__VA_ARGS__)
+
+/* Print "core-load" enter/exit debug statements.  */
+
+#define CORE_LOAD_SCOPED_DEBUG_ENTER_EXIT \
+  scoped_debug_enter_exit (debug_core_load, "core-load")
+
 /* Forward declarations.  */
 
 static void core_target_open (const char *arg, int from_tty);
@@ -365,6 +388,8 @@ core_target::core_target ()
 void
 core_target::build_file_mappings ()
 {
+  CORE_LOAD_SCOPED_DEBUG_ENTER_EXIT;
+
   /* Type holding information about a single file mapped into the inferior
      at the point when the core file was created.  Associates a build-id
      with the list of regions the file is mapped into.  */
@@ -426,6 +451,14 @@ core_target::build_file_mappings ()
     [&] (int num, ULONGEST start, ULONGEST end, ULONGEST file_ofs,
 	 const char *filename, const bfd_build_id *build_id)
       {
+
+	core_load_debug_printf ("start = 0x%s, end = 0x%s, filename = %s, build-id = %s",
+				phex_nz (start), phex_nz (end),
+				(filename == nullptr ? "NONE" : filename),
+				(build_id == nullptr
+				 ? "NONE"
+				 : build_id_to_string (build_id).c_str ()));
+
 	/* Architecture-specific read_core_mapping methods are expected to
 	   weed out non-file-backed mappings.  */
 	gdb_assert (filename != nullptr);
@@ -2175,4 +2208,13 @@ INIT_GDB_FILE (corelow)
 	   maintenance_print_core_file_backed_mappings,
 	   _("Print core file's file-backed mappings."),
 	   &maintenanceprintlist);
+
+  /* Debug this files internals.  */
+  add_setshow_boolean_cmd ("core-load", class_maintenance, &debug_core_load,  _("\
+Set core-load debugging."), _("\
+Show core-load debugging."), _("\
+When on, core-load specific internal debugging is enabled."),
+			   NULL,
+			   show_core_load_debug,
+			   &setdebuglist, &showdebuglist);
 }