From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kGr7GwnprmkWKSAAWB0awg (envelope-from ) for ; Mon, 09 Mar 2026 11:36:41 -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=xSvzjKd9; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5F7FD1E0DD; Mon, 09 Mar 2026 11:36:41 -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 60D891E089 for ; Mon, 09 Mar 2026 11:36:40 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 6C0264BA23D3 for ; Mon, 9 Mar 2026 15:36:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C0264BA23D3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1773070599; bh=lnupiLEEUFry9Jw1k5hfakj8JHUZvSSPf94jWKXbRzk=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=xSvzjKd9z9vSKvaYC9/4wiiDQSIQ87KiShwgOXNKHfr+hYPs5sW6Iw/hJJzh43WF3 NVUn9hP/tFSuOaP6W+KA1GCdXnCAPfTyVtQtpsj0FLPUOFhjihhte0GAYAfJWsbW4Q yf1oNQbxXFqMCb9aaSqEPaJu9OzySUHgrsVUEwFc= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C00C34BA2E0E for ; Mon, 9 Mar 2026 15:36:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C00C34BA2E0E ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C00C34BA2E0E ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773070562; cv=none; b=GhwsYuL9IAwD63cjKYG42w4/Fc5ttXyJQ7JsdNGpOz+ttkOoZu8v+oFlmSX2s/FvuoLXV/+5S6PlRsK7P/Hk1RWtkiG5xhLlpmrIQxZxJYt7s/Dwx0Ex1upknxlIao/xtbZ4mRTaHYz4XtewypsQVUC5JvICPZYKbS4gzGUUw+0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773070562; c=relaxed/simple; bh=W2MUaJuLHCa3TkoFdyYMS6tqH8i3hs8VmKnNzq59pEc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ZUqC8hVZ6bJVfS9S/oLO7fBDx5fipw45dhJwvgkD6eXvx21tVhrdFwQr9KBPM0HyG6SGpJm8Q6Z8UAcIW6n//Trx+XcCCNHZ0DokDS8YeeHYAwmxZXOdTkqXkEj0z1omQ0+c1ohwnaGsfIlFHaZX5c5dObBhSNUQNsynjAyh+R4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C00C34BA2E0E Received: by simark.ca (Postfix) id 189301E089; Mon, 09 Mar 2026 11:36:01 -0400 (EDT) Message-ID: <371fdb1a-2c5d-40cd-9294-03e2a5040e06@simark.ca> Date: Mon, 9 Mar 2026 11:36:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Does gdb debuginfod download libc etc.? To: psmith@gnu.org, =?UTF-8?Q?Arsen_Arsenovi=C4=87?= Cc: gdb@sourceware.org References: <86wlzmfyep.fsf@aarsen.me> <4844fe241f5524951dc68a6ce05e450897342034.camel@gnu.org> <8c514818-14bd-462d-8aed-0c323327acae@simark.ca> <7949b3d7727ab11f6bc3c833fae81f485c345c47.camel@gnu.org> Content-Language: fr In-Reply-To: <7949b3d7727ab11f6bc3c833fae81f485c345c47.camel@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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