debuginfod-find queries one or more debuginfod servers for debuginfo-related data. In case of a match,
it saves the the requested file into a local cache, prints the file name to standard output, and exits
with a success status of 0. In case of any error, it exits with a failure status and an error message to
standard error.
The debuginfod system uses buildids to identify debuginfo-related data. These are stored as binary notes
in ELF/DWARF files, and are represented as lowercase hexadecimal. For example, for a program /bin/ls,
look at the ELF note GNU_BUILD_ID:
% readelf -n /bin/ls | grep -A4 build.id
Note section [ 4] '.note.gnu.buildid' of 36 bytes at offset 0x340:
Owner Data size Type
GNU 20 GNU_BUILD_ID
Build ID: 8713b9c3fb8a720137a4a08b325905c7aaf8429d
Then the hexadecimal BUILDID is simply:
8713b9c3fb8a720137a4a08b325905c7aaf8429d
In place of the hexadecimal BUILDID, debuginfod-find also accepts a path name to to an ELF binary, from
which it extracts the buildid. In this case, ensure the file name has some character other than [0-9a-f]. Files ambiguously named files like "deadbeef" can be passed with a ./deadbeef extra path component.
debuginfoBUILDID
If the given buildid is known to a server, this request will result in a binary object that contains the
customary .*debug_* sections. This may be a split debuginfo file as created by strip, or it may be an
original unstripped executable.
executableBUILDID
If the given buildid is known to the server, this request will result in a binary object that contains
the normal executable segments. This may be a executable stripped by strip, or it may be an original un‐
stripped executable. ET_DYN shared libraries are considered to be a type of executable.
sourceBUILDID/SOURCE/FILE
If the given buildid is known to the server, this request will result in a binary object that contains
the source file mentioned. The path should be absolute. Relative path names commonly appear in the
DWARF file's source directory, but these paths are relative to individual compilation unit AT_comp_dir
paths, and yet an executable is made up of multiple CUs. Therefore, to disambiguate, debuginfod expects
source queries to prefix relative path names with the CU compilation-directory, followed by a mandatory
"/".
Note: for software packaged by distributions, the CU compilation-directory may not be obvious. It can be
found by inspecting AT_comp_dir values in downloaded debuginfo. For example, the comp_dir of the Fedora
37 version of /bin/ls can be found as follows:
% debuginfod-find debuginfo /bin/ls~/.cache/debuginfod_client/03529d48345409576cd5c82a56ad08555088d353/
% eu-readelf -w ~/.cache/debuginfod_client/03529d48345409576cd5c82a56ad08555088d353/debuginfo | grep comp_dir
comp_dir (line_strp) "/usr/src/debug/coreutils-9.1-6.fc37.x86_64/separate"
Note: the caller may or may not elide ../ or /./ or extraneous /// sorts of path components in the direc‐
tory names. debuginfod accepts both forms. Specifically, debuginfod canonicalizes path names according
to RFC3986 section 5.2.4 (Remove Dot Segments), plus reducing any // to / in the path.
For example:
#include <stdio.h> source BUILDID /usr/include/stdio.h
/path/to/foo.c source BUILDID /path/to/foo.c
../bar/foo.c AT_comp_dir=/zoo/ source BUILDID /zoo//../bar/foo.c
metadataKEYVALUE
All designated debuginfod servers are queried for metadata about all files that match a given key/value
query in their index. The results include names and buildids, which may be used in future queries to
fetch actual files.
KEY VALUE DESCRIPTION
filepath exact match path, including in archives
globpattern shell-style glob match pattern, including in archives, as in fnmatch(FNM_PATHNAME)
The resulting output will look something like the following {
"results":[
{
"type":"executable",
"buildid":"f0aa15b8aba4f3c28cac3c2a73801fefa644a9f2",
"file":"/usr/local/bin/hello",
"archive":"/opt/elfutils/tests/test-2290642/R/rhel7/hello2-1.0-2.x86_64.rpm"
},
{
"type":"executable",
"buildid":"bc1febfd03ca05e030f0d205f7659db29f8a4b30",
"file":"hello2"
}
],
"complete":true }'
The results of the search are output to stdout as a JSON object containing an array of objects, supplying
metadata about each match, as well as a boolean value corresponding to the completeness of the result.
The result is considered complete if all of the queries to upstream servers returned complete results and
the local query succeeded. This metadata report may be cached. It may be incomplete and may contain du‐
plicates. Additional JSON object fields may be present.
NAME TYPE DESCRIPTION
buildid string hexadecimal buildid associated with the file
type string one of debuginfo or executablefile string matched file name, outside or inside the archive
archive string archive containing matched file name, if any
It's worth noting that type cannot be source since in order to perform such a search fast enough addi‐
tional indexing would need to be added to the database which would nearly double it's size.
The search also always combines both files and archives in the results and at this time further granular‐
ity is not availible.
Install Now
PNG Icons
