debuginfod-find - Man Page

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.

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 unstripped executable.  ET_DYN shared libraries are considered to be a type of executable.

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 directory 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:

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.

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 duplicates.   Additional JSON object fields may be present.

It's worth noting that type cannot be source since in order to perform such a search fast enough additional 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 granularity is not availible.