www.LinuxHowtos.org howtos, tips&tricks and tutorials for linux

from small one page howto to huge articles all in one place

Other .linuxhowtos.org sites:gentoo.linuxhowtos.org

Last additions:

using iotop to find disk usage hogs

words:

887

views:

209586

userrating:

May 25th. 2007:

Words

486

Views

258592

why adblockers are bad

Workaround and fixes for the current Core Dump Handling vulnerability affected kernels

words:

161

views:

149883

userrating:

April, 26th. 2006:

Words

Views

107374

New subdomain: toolsntoys.linuxhowtos.org

You are here: manpages

DEBUGINFO-FIND

Section: User Commands (1)
Index Return to Main Contents

NAME

debuginfo-find - request debuginf-related data

SYNOPSIS

debuginfo-find [OPTION]... debuginfo BUILDID
debuginfo-find [OPTION]... debuginfo PATH
debuginfo-find [OPTION]... executable BUILDID
debuginfo-find [OPTION]... executable PATH
debuginfo-find [OPTION]... source BUILDID /FILENAME
debuginfo-find [OPTION]... source PATH /FILENAME
debuginfo-find [OPTION]... metadata KEY VALUE

DESCRIPTION

debuginfo-find queries one or more debuginfod servers for debuginf-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 debuginf-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, debuginfo-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 [-9-f]. Files ambiguously named files like "deadbeef" can be passed with a ./deadbeef extra path component.

debuginfo BUILDID

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.

executable BUILDID

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.

source BUILDID /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 compilatio-directory, followed by a mandatory "/".

Note: for software packaged by distributions, the CU compilatio-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:

% debuginfo-find debuginfo /bin/ls
~/.cache/debuginfod_client/03529d48345409576cd5c82a56ad08555088d353/
% e-readelf-w ~/.cache/debuginfod_client/03529d48345409576cd5c82a56ad08555088d353/debuginfo | grep comp_dir
           comp_dir             (line_strp) "/usr/src/debug/coreutil-9.-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:

#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

metadata KEY VALUE

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

file	path	exact match path, including in archives
glob	pattern	shel-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/tes-2290642/R/rhel7/hello-1.-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.

NAME	TYPE	DESCRIPTION

buildid	string	hexadecimal buildid associated with the file
type	string	one of debuginfo or executable
file	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 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.

OPTIONS

-v

Increase verbosity, including printing frequent downloa-progress messages and printing the http response headers from the server.

SECURITY

If IMA signature(s) are available from the RPMs that contain requested files, then debuginfod will extract those signatures into response headers, and debuginfo-find will perform verification upon the files. Validation policy is controlled via tags inserted into $DEBUGINFOD_URLS. By default, debuginfo-find acts in ignore mode.

If accessed across HTTP rather than HTTPS, the network should be trustworthy. Authentication information through the internal libcurl library is not currently enabled, except for the basic plaintext http[s]://userid:password@hostname/ style. (The debuginfod server does not perform authentication, but a fron-end proxy server could.)