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 <dth...@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 | dth...@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+unsubscr...@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+unsubscr...@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> > . >
