From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CQa5BuLRrmnl3x8AWB0awg (envelope-from ) for ; Mon, 09 Mar 2026 09:57:54 -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=sdk8mQK8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 15B241E0DD; Mon, 09 Mar 2026 09:57:54 -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=unavailable 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 DC3071E08D for ; Mon, 09 Mar 2026 09:57:52 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 68F674BA23C7 for ; Mon, 9 Mar 2026 13:57:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68F674BA23C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1773064672; bh=HiTNmu8Y46FFbsru5tqYEaBC5dygSual6HWGz23dv+s=; h=Subject:To:Cc:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=sdk8mQK8hTAPqtsTEwC9PXCmr1CYJlcrl83nar/+o85zpRFi/2MzTmc+PEihSh4kZ yFByAUMEg2H3MNg9Sp/7NbcaO//4H+C69+tQcciG/f3bXfRuWIsqB2t1p4WRlww/No rLDWQJoU7YF8qsMXK4CBqBcCmqdW4x5NyGfsj4NU= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 79F244BA2E0E for ; Mon, 9 Mar 2026 13:57:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 79F244BA2E0E ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 79F244BA2E0E ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773064638; cv=none; b=qj/jbEyY6p5ldhjmSfCm5uHVwowpHVIgkfa7YW6Dhak5BRoqtbjqi+8bsDoR4y5kf1jeWK/jcf78o4cvb3Hcov6SWy8f8B+oFH73mT4bDThOfcwg8lAYrunWYR61Ky/BpN7CLWqgV+mff7cDA92p3BcI7qC7g5dzQdxSROQ2tS0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773064638; c=relaxed/simple; bh=ZNtcxkrhvG2Uof31TnxMr9EHz2mpP49i14GI5BVuSGw=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=u0NzlSD+B12Y1SmBDCNzJWGfI+QLYxi1NdQ8wTxxVlsdkbRvKq1HiaUjWKfvFzmvXWUPWCEETiBCF8Po7ub+8uftZiIbaQUroI4JxY4oCcY2imTvzemCkY1sxhp0aqA8hKJ5eX37amxpenpmr0/iOFIJtQjNyKqc66sfLSnlKPQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79F244BA2E0E Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vzb6e-0007Fd-IZ; Mon, 09 Mar 2026 09:57:12 -0400 Message-ID: <7949b3d7727ab11f6bc3c833fae81f485c345c47.camel@gnu.org> Subject: Re: Does gdb debuginfod download libc etc.? To: Simon Marchi , Arsen =?UTF-8?Q?Arsenovi=C4=87?= Cc: gdb@sourceware.org Date: Mon, 09 Mar 2026 09:57:11 -0400 In-Reply-To: <8c514818-14bd-462d-8aed-0c323327acae@simark.ca> References: <86wlzmfyep.fsf@aarsen.me> <4844fe241f5524951dc68a6ce05e450897342034.camel@gnu.org> <8c514818-14bd-462d-8aed-0c323327acae@simark.ca> Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (by Flathub.org) MIME-Version: 1.0 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: Paul Smith via Gdb Reply-To: psmith@gnu.org Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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 f87c1d8cd2118209ef2350b22b187a64d705d6c= d 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 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. > > > =E2=9A=A0=EF=B8=8F warning: platform-specific solib_create_inferior_h= ook did not > > > load initial shared libraries. >=20 > 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=3D9 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!