From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 3162C3858C53 for ; Wed, 14 Jun 2023 15:57:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3162C3858C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id ED416313ACBE; Wed, 14 Jun 2023 17:57:25 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id 7869C3402E2; Wed, 14 Jun 2023 17:57:24 +0200 (CEST) Message-ID: Subject: Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH) From: Mark Wielaard To: Roland McGrath , Daniel Thornburgh Cc: elfutils-devel@sourceware.org Date: Wed, 14 Jun 2023 17:57:24 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 (3.48.3-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-3028.2 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Roland, On Wed, 2023-05-31 at 16:44 -0700, Roland McGrath via Elfutils-devel wrote: > In elfutils, the libdwfl library is responsible for the "library for > obtaining debug info writ large" stuff. It provides API parsers > for command-line arguments that mesh with its library stuff like > Dwfl_Callbacks that set the search path used equivalently to GDB's `set > debug-file-directory` path. eu-* tools as well as things like systemtap u= se > this to accept `--debuginfo-path=3DPATH`, but AFAIK none of them support > environment variables. In the binutils world outside of GDB itself, I > think only objdump and readelf do .build-id/... lookup and those use comm= on > binutils-private code (binutils/dwarf.c) that just has a hard-coded > directory list. Some more uniformity here would be beneficial to everyon= e, > I think. One difference is that the elfutils and gdb traditional "search path" mechanism is mainly based on path/file names (lookups through .gnu_debuglink, possibly relative .debug dirs/files) while the primary lookup method for libdebuginfod is based on build-id. libdebuginfod kind of assumes you already know the traditional lookup didn't work. That is also how dwfl_standard_find_debuginfo uses libdebuginfod. It first gets the build-id from the ELF file, looks for that in the traditional way (/usr/lib/debug/.build-id/xx/yyyy.debug), if that fails it does a path based search (using the file name, debuglink file name and Dwfl_Callbacks debuginfo_path), and if that also fails then it tries to use libdebuginfod. Another difference is the lookup of .dwz files. Since they contain an "artificial" build-id, libdebuginfod uses that to look them up as if a "normal" .debug file. While the traditional lookup uses the (relative!) path in the .gnu_debugaltlink section of the .debug file. I wonder which parts of the "traditional" lookup are still useful/relevant. Could we get away with pointing at a "traditional" /usr/lib/debug/ like path that contains a .build-id and (optional) .dwz subdir to make libdebuginfo that "uniform" debug file lookup library? Cheers, Mark