From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 0827838708D9; Wed, 24 Feb 2021 15:07:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0827838708D9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@tarox.wildebeest.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id D444C301B4B0; Wed, 24 Feb 2021 16:07:52 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id B687C41A0382; Wed, 24 Feb 2021 16:07:52 +0100 (CET) Date: Wed, 24 Feb 2021 16:07:52 +0100 From: Mark Wielaard To: Tom Tromey Cc: gdb-patches@sourceware.org, elfutils-devel@sourceware.org, dwz@sourceware.org Subject: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections) Message-ID: <20210224150752.GA23884@tarox.wildebeest.org> References: <20210221231810.1062175-1-tom@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210221231810.1062175-1-tom@tromey.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-39.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 15:07:55 -0000 Hi, I am adding the elfutils and dwz mailinglists to CC because I think you stumbled upon a silent assumption debuginfod makes which would be good to make explicit (or maybe change?) Context is that dwz 0.15 (still not released yet) can now produce standardized DWARF Supplementary Files using a .debug_sup section when using --dwarf-5 -m multifile. See this bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=27440 The full patch to support that in gdb is here: https://sourceware.org/pipermail/gdb-patches/2021-February/176508.html But what I like to discuss is this part of Tom's email: On Sun, Feb 21, 2021 at 04:18:10PM -0700, Tom Tromey wrote: > DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in > multi-file mode. This is handled via some new forms, and a new > .debug_sup section. > > This patch adds support for this to gdb. It is largely > straightforward, I think, though one oddity is that I chose not to > have this code search the system build-id directories for the > supplementary file. My feeling was that, while it makes sense for a > distro to unify the build-id concept with the hash stored in the > .debug_sup section, there's no intrinsic need to do so. Tom is correct. Technically a supplemental (alt) file id isn't a build-id. But it does smell like one. It is a large globally unique identifier that can be expressed as hex string. And the GNU extension defining alt files for DWARF < 5 (and still with DWARF5 currently by default because no consumer yet supports .debug_sup) will put it in a .note.gnu.build-id NOTE section as GNU_BUILD_ID. This has the nice side-effect that a distro will most likely make it available as /usr/lib/debug/.build-id/xx/yyyy.debug file. And that "build-id" is how you request it from debuginfod (you request /buildid/BUILDID/debuginfo). Now technically that is cheating and confusing two concepts, the build-id and supplemental file id. But I was personally assuming we would extend it to also to other things like dwo IDs (which are again almost identical globally unique identifiers for files). There one question would be if you would get the .dwo file or the .dwp file in which is was embedded (I would vote for the second). One consequence of conflating all these IDs is that it isn't immediately clear what a debuginfod request for /buildid/BUILDID/executable should return (probably nothing). Or if /buildid/BUILDID/source/SOURCE/FILE requests also (should) work for other IDs than build-ids. Any opinions on whether we should split these concepts out and introduce separate request mechanisms per ID-kind, or simply assume a globally unique id is globally unique and we just clarify what it means to use a build-id, sup_checksum or dwo_id together with a request for an executable, debuginfo or source/file? Thanks, Mark