Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)

[Paul Smith <paul@mad-scientist.net>]

On Wed, 2023-05-31 at 15:17 -0700, Daniel Thornburgh via Elfutils-devel
wrote:
> 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.

Having content in /usr/lib is less good.  It's perfect for allowing
package managers to install debug info files for packages, but it's not
good for allowing users to either download or "publish" their own info
files.

Couldn't the standard XDG environment variables be used to generate a
search path or paths, rather than inventing new ones (or, the new
variable can be used to override the default which is computed based on
XDG), to find the user's personal build ID directories?  This location
can be updated without root, can easily be made available inside
containers (flatpak / snap), etc.

If everyone could agree on a naming convention so that all tools that
need debug info could write them to a common location after download
(or even on generation), and check that location for files first before
querying debuginfod, that would be a great "it just works" feature and
avoid a lot of duplication.

Or, maybe I'm just misunderstanding something :).