In elfutils, the libdwfl library is responsible for the "library for
obtaining debug info writ large" stuff. It provides <argp.h> 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 use
this to accept `--debuginfo-path=PATH`, 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 common
binutils-private code (binutils/dwarf.c) that just has a hard-coded
directory list.  Some more uniformity here would be beneficial to everyone,
I think.

On Wed, May 31, 2023 at 3:17 PM Daniel Thornburgh <dthorn@google.com> wrote:

> Hi elfutils-devel@,
>
> I've been working on adding debuginfod support to various LLVM utilities,
> while simultaneously setting up production use of debuginfod for a managed
> developer environment.
>
> One issue that keeps cropping up is that there's often quite a few places
> to get debug files from locally, in addition to various remote backends.
> For example, the output of local build systems, prebuilt packages and
> tarballs that a developer is working on, etc.
>
> One of the best things about debuginfod is that you can set up a service
> once, then point an astonishingly wide array of tools at the server, with
> one configuration.
>
> This isn't the case for files available locally, but there is some prior
> art: GDB's build ID directory layout (commonly
> `/usr/lib/debug/.build-id/<first 2 chars of build ID>/<remainder of build
> ID>`). GDB has a flag to control this (`--with-separate-debug-dir`), but
> that flag isn't shared by other tools. For example, binutils supports this
> layout, but it simply hardcodes a list of directories to search for, with
> no way to extend or override it. LLVM also supports this, but has a
> differently named flag for it.
>
> Local files can be served to localhost using a debuginfod server, but this
> incurs the overhead of transferring the files over a local socket on first
> access, and the much worse overhead of storing an additional copy of the
> file on disk in the debuginfod cache. With sufficiently large projects,
> this gets pretty rough.
>
> It would be really nice if there were, a DEBUGINFOD_LOCAL_PATH environment
> variable that provided a colon-separated list of directories in the GDB
> `.build-id/<xx>/<xxxxxx>` format to locally fetch files out of before
> attempting remote servers. This would allow imbuing local build ID fetching
> to tools that wouldn't otherwise support it, with one common configuration
> language for how to do it.
>
> I did definitely want to raise this on the mailing list before starting to
> implement something like this though, since it increases the scope of
> libdebuginfod to include local fetching out of more than just out of its
> own cache. It would stretch debuginfod towards a more general "library for
> obtaining debug info writ large", rather than a straightforward remote
> client library.
>
> Daniel Thornburgh | dthorn@google.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "(retired) tq-toolchain-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tq-toolchain-team+unsubscribe@google.com.
> To view this discussion on the web visit
> https://groups.google.com/a/google.com/d/msgid/tq-toolchain-team/CAEdiOyeCSvpUijvZwJ%3DW2ncsGokefdm8z3yKVG%2Bu4jkAgXcumw%40mail.gmail.com
> <https://groups.google.com/a/google.com/d/msgid/tq-toolchain-team/CAEdiOyeCSvpUijvZwJ%3DW2ncsGokefdm8z3yKVG%2Bu4jkAgXcumw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "rvos-toolchain-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rvos-toolchain-team+unsubscribe@google.com.
> To view this discussion on the web visit
> https://groups.google.com/a/google.com/d/msgid/rvos-toolchain-team/CAEdiOyeCSvpUijvZwJ%3DW2ncsGokefdm8z3yKVG%2Bu4jkAgXcumw%40mail.gmail.com
> <https://groups.google.com/a/google.com/d/msgid/rvos-toolchain-team/CAEdiOyeCSvpUijvZwJ%3DW2ncsGokefdm8z3yKVG%2Bu4jkAgXcumw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>