From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lwBpCojgr2noaCEAWB0awg (envelope-from ) for ; Tue, 10 Mar 2026 05:12:40 -0400 Received: by simark.ca (Postfix, from userid 112) id 0CDB11E0DD; Tue, 10 Mar 2026 05:12:40 -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.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 8FD971E08D for ; Tue, 10 Mar 2026 05:12:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 925424BA2E1C for ; Tue, 10 Mar 2026 09:12:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 925424BA2E1C Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 793A74BA2E1A for ; Tue, 10 Mar 2026 09:12:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 793A74BA2E1A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 793A74BA2E1A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773133924; cv=none; b=CRU8xK0wEpEkGdpETSFFAXbRmVZwUKx+SVAtBdTALoX6OsygVf7EVxSjuo7IRbZxTUEl/BWQf+Ej7G1TheQ2RBG3IoQv2WziprJH3OfPEIJIo7B3P2N0BCUq4O8C+skj1lixqloWUkAcSL6rC23a8AsyADuduCRjKwGjRzsTzB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773133924; c=relaxed/simple; bh=X1Xcf246MJrPzDZH0C1/g0LsG1zAR6ZauoIePdnRAG8=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=ZqIjAqmEg35B8mQ5xVJ7nGxoHc5wbwrUlhTAjAusX+nILofLab/gXTVFWGIO+QP9y3ucB3qb7BISkwNh6gDeiMZX4pG9aTrltH9z2qpTnLL5QSautyQ1NJKAN2rSRE8GxID3nghcQqKt4mopW8QXrNsS1srMFd0hfrftQXYeWr8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 793A74BA2E1A Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 62CF53032F85; Tue, 10 Mar 2026 10:12:03 +0100 (CET) Date: Tue, 10 Mar 2026 10:12:03 +0100 From: Mark Wielaard To: psmith@gnu.org Cc: Andrew Burgess , gdb@sourceware.org Subject: Re: Does gdb debuginfod download libc etc.? Message-ID: <20260310091203.GB5634@gnu.wildebeest.org> References: <86wlzmfyep.fsf@aarsen.me> <4844fe241f5524951dc68a6ce05e450897342034.camel@gnu.org> <8c514818-14bd-462d-8aed-0c323327acae@simark.ca> <7949b3d7727ab11f6bc3c833fae81f485c345c47.camel@gnu.org> <87ldg16ivz.fsf@redhat.com> <421fe2ad615c4af1443ddbd3955ee65cb7feb9ee.camel@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: , Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hi Paul, On Mon, Mar 09, 2026 at 05:19:44PM -0400, Paul Smith via Gdb wrote: > (Most of) my core files are generated by the Google coredumper library, > not by the Linux kernel, and I guess they don't have this note section. > > It appears that this note section isn't actually required in order for > us to access the build ID values (after all, elfutils does it), but > this function gives up if the section doesn't exist. > > I can look into how to force my cores to have this section, but I'd > really like to teach GDB how to handle core files without it, since I > have a lot of them and will likely continue to get them for some time > even if I do manage to make this change to new releases. Not sure this helps, since I know very little about gdb/bfd, but the way elfutils gets at the build-id is to represent each core PT_LOAD as an Elf and then tries to read the NOTEs either through the section headers or the program headers. See https://sourceware.org/cgit/elfutils/tree/libdwelf/dwelf_elf_gnu_build_id.c This is somewhat simpler in elfutils because it just deals with ELF files and doesn't care about other binary formats. Maybe there is a simple mapping from bfd to elf sections/segements to do the same? Cheers, Mark