From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aR6xIgv8rmmMZyAAWB0awg (envelope-from ) for ; Mon, 09 Mar 2026 12:57:47 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=kKFAmxA/; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 845771E0DD; Mon, 09 Mar 2026 12:57:47 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5E0F51E089 for ; Mon, 09 Mar 2026 12:57:46 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id ECDB74BA2E10 for ; Mon, 9 Mar 2026 16:57:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECDB74BA2E10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1773075466; bh=dpUlnZq82y4c5WcKFcyHTRRfe94y841mkQ/bwSVkENI=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=kKFAmxA/1k/ojOVhy0qZXkkwsgNvrxgCh1+NPzUzq2mzhh3nr6Le5zNGRJu5AJREL EmtCIgnwJDbe947e/FsWD1i4oDQOrx7znS2wHtckqlQP1GX6+Nfzf1XDvNnqp1GNoA nCR2jtYZRV0HG5Eqrn20u5Met5PWcZ29Fq0e/PhU= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C71C94BA2E0B for ; Mon, 9 Mar 2026 16:57:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C71C94BA2E0B ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C71C94BA2E0B ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773075429; cv=none; b=P5RCPkp1YCyJypXfqL/63NbUCKcEe75hDUbN8ELwd6WBYrdg7qXc/CXC2Oh1wIIxAOylppwT/xBaWcOFi2m4pLE+XJr1tfKFjYA1TBvqCNMzd4QHO6QjHbIpP96PgTK7kM6fauooprsMCxWwjM2k+7qintgUDjYldwq7RjRtlMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773075429; c=relaxed/simple; bh=SMVxoJy/y48T5KpImK1vnjWv0GdPW/e/BqevSblCQ04=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OyOZK4zFoQydY0BdfvQJialjrHgVwVCAZr2RkHWaKYyCIacdx8GBP2LlFsnqonwfvzFMGDC0p6SP4ebjHXfwgBa7GkDziQB+xoFBuAq8QtDAGb9tkB+YaT/egfMKIjegqBHrd1RTfKcCdbtmAKnWuAE1fs6dG9we3PvW5U3cI3Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C71C94BA2E0B Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-690-qASeb7HoPLCIygZuOJ6l8g-1; Mon, 09 Mar 2026 12:57:08 -0400 X-MC-Unique: qASeb7HoPLCIygZuOJ6l8g-1 X-Mimecast-MFC-AGG-ID: qASeb7HoPLCIygZuOJ6l8g_1773075427 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-485389bf0daso8644555e9.0 for ; Mon, 09 Mar 2026 09:57:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773075427; x=1773680227; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=ptZlCSw4l47ziYc5YN25pVfUcrn33TAu2OSp38qavGs=; b=B5rpFspIji8mczy3biPMtSoDMApFM+Fkj3SMRzm0aNkYffd1TBQNYYEVYcF8k3tGn/ wcbvaoRa6wh5Cc5SIgqVT4KZXebu4oc7EiyM4xiYrXcQVJiEQeTEXMq6F+NYCd2D65aF zBjhAobP5fAz2To0kH91QtJYEYMOz0ihxZmaCzYi1zFw6DOMxJAFGamRNYnXtf1c1KWL oxrVCHmzi6C6ODHyricKxCpKfavJJ67iPaMFg0dESf3iHEZElkNHJzTVvY4xIZuZqlvv r24q+4rThHoOI4BWR2fktgq2UkjbhpSw6YMb8thTcUpWiJhcMVX0O6SMtdp+CsVA6Hr6 jxjg== X-Gm-Message-State: AOJu0YyZ+M6Xw7QWLoxy/xeRt7/BXjg5nAKGFzih/TnwQWSVYE2jOKt7 efjDOAnblziKbnEBHDilegtduAb3ulgnZ4bvTu+iU8WjahS+MzUieLfWrsXcDo0IKBwIaFU06MF +CpLb7j5SPuvNWNvwAnjLh71EzRuwVH3rz80vYekVyjAu+nQ7sKem X-Gm-Gg: ATEYQzwvY5G/f+q5Aq82uUxw6LYM76bA8hpgS7UeZUWOuNd7JVoeBnwH+M6XL8IF3JR vfxjsdjciVTSeHWCQWh5ed2f11NTqjDjVf9C+Fu/hWUUFgOKOI8fARCFX56zO6EM61M5OjW1Quj b5DDAPE+FubPmwh4iLy7taQUzyfAZgvNgRaSkXFObHUtxuRn/h6iXkQ3S7UprqTnjsX/JYoGUD7 VnssTtDPh5o2g+khMl47EaAUxvFQG4nK8SIybl28JLrbhuQKK/m0V8kF3GT9Cc8x6QkZJ0e5ocx LDtUy7UhmrfxIckUvZcdopAknnA2anAtQQ1YGZ3SDzB0i8NpZNdLHRfaRv4SXmEBwRhMYcmvUyU Gxb0pwg+Qhs1LGDmi X-Received: by 2002:a05:600c:1395:b0:485:2fc5:3b0 with SMTP id 5b1f17b1804b1-4852fc506a5mr139693665e9.27.1773075426909; Mon, 09 Mar 2026 09:57:06 -0700 (PDT) X-Received: by 2002:a05:600c:1395:b0:485:2fc5:3b0 with SMTP id 5b1f17b1804b1-4852fc506a5mr139693185e9.27.1773075426366; Mon, 09 Mar 2026 09:57:06 -0700 (PDT) Received: from localhost ([31.111.84.232]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485354f96fesm47938375e9.30.2026.03.09.09.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 09:57:05 -0700 (PDT) To: psmith@gnu.org, Simon Marchi , Arsen =?utf-8?Q?Arsen?= =?utf-8?Q?ovi=C4=87?= Cc: gdb@sourceware.org Subject: Re: Does gdb debuginfod download libc etc.? In-Reply-To: <7949b3d7727ab11f6bc3c833fae81f485c345c47.camel@gnu.org> References: <86wlzmfyep.fsf@aarsen.me> <4844fe241f5524951dc68a6ce05e450897342034.camel@gnu.org> <8c514818-14bd-462d-8aed-0c323327acae@simark.ca> <7949b3d7727ab11f6bc3c833fae81f485c345c47.camel@gnu.org> Date: Mon, 09 Mar 2026 16:57:04 +0000 Message-ID: <87ldg16ivz.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Ib2uNfr05E_YA14CpeO3qYkyBKsR81rUE_QbgsHBxA8_1773075427 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Paul Smith via Gdb 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).=C2=A0 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: >>=20 >> =C2=A0 debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6= cd > > 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: >>=20 >> =C2=A0 debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8c= f > > 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.=20 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=20 (gdb) core-file ~/core.54313=20 [core-load] build_file_mappings: enter [core-load] operator(): start =3D 0x400000, end =3D 0x407000, filename = =3D /some/program, build-id =3D a004xxxx178xxxx78xxxx6c6cxxxx800df88xxxx [core-load] operator(): start =3D 0x407000, end =3D 0x41e000, filename = =3D /some/program, build-id =3D NONE [core-load] operator(): start =3D 0x41e000, end =3D 0x427000, filename = =3D /some/program, build-id =3D NONE [core-load] operator(): start =3D 0x428000, end =3D 0x429000, filename = =3D /some/program, build-id =3D 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 =20 +/* When true emit 'core-load' debug messages. */ + +static bool debug_core_load =3D false; + +/* Handle 'show debug core-load' command. */ + +static void +show_core_load_debug (struct ui_file *file, int from_tty, +=09=09 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_AR= GS__) + +/* 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. */ =20 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, =09 const char *filename, const bfd_build_id *build_id) { + +=09core_load_debug_printf ("start =3D 0x%s, end =3D 0x%s, filename =3D %s,= build-id =3D %s", +=09=09=09=09phex_nz (start), phex_nz (end), +=09=09=09=09(filename =3D=3D nullptr ? "NONE" : filename), +=09=09=09=09(build_id =3D=3D nullptr +=09=09=09=09 ? "NONE" +=09=09=09=09 : build_id_to_string (build_id).c_str ())); + =09/* Architecture-specific read_core_mapping methods are expected to =09 weed out non-file-backed mappings. */ =09gdb_assert (filename !=3D nullptr); @@ -2175,4 +2208,13 @@ INIT_GDB_FILE (corelow) =09 maintenance_print_core_file_backed_mappings, =09 _("Print core file's file-backed mappings."), =09 &maintenanceprintlist); + + /* Debug this files internals. */ + add_setshow_boolean_cmd ("core-load", class_maintenance, &debug_core_loa= d, _("\ +Set core-load debugging."), _("\ +Show core-load debugging."), _("\ +When on, core-load specific internal debugging is enabled."), +=09=09=09 NULL, +=09=09=09 show_core_load_debug, +=09=09=09 &setdebuglist, &showdebuglist); }