Proposal: DEBUGPATH environment variable for build-id based symbol lookups

In remote/embedded development scenarios we have a tree of binaries with debug information on the host and a debugging setup on the target that reports build ids for loaded binaries to the host. In this setup we would like to be able to support local symbol file lookups by build-id. However, currently we only support /usr/lib/debug as the default search path for local symbol file lookups by build-id in llvm-symbolizer and LLDB, which is only suitable for build-id based lookup of host binaries. I checked the logic in GNU binutils and gdb and it is basically the same situation.

It is possible to override the search path but this can only be done on a per-tool basis. For example, llvm-symbolizer accepts a --debug-file-directory command line flag and in LLDB we can set the target.debug-file-search-paths property. However, ideally I shouldn’t need to configure each tool separately. Instead I should be able to configure build-id lookups in all tools using an environment variable, similarly to how exporting DEBUGINFOD_URLS configures all tools to use a specific debuginfod server. With that, it would become possible to adjust scripts that are used to begin development/debugging the remote target to set the variable, and all tools would then be able to find symbols. For example, Android could set this variable in envsetup.sh as proposed here.

This is a fairly simple proposal to allow the default search path for build-id based lookups to be overridden by setting an environment variable called DEBUGPATH. This would be a colon-separated list of search paths for build-id based lookups. Setting this environment variable would cause llvm-symbolizer and LLDB to use the specified list of search paths instead of /usr/lib/debug. We can also inform GNU binutils of this proposal so that GNU tools will also respect DEBUGPATH. I did a Google search for "export DEBUGPATH" which did not find any pre-existing usage of this environment variable name, so it seems unlikely that this will change tool behavior for existing users.