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