..

 #include <elfutils/debuginfod.h> 

Link with -ldebuginfod.

CONNECTION HANDLE

 "debuginfod_client *debuginfod_begin(void);"  "void debuginfod_end(debuginfod_client *" client ");" 
LOOKUP FUNCTIONS

 "int debuginfod_find_debuginfo(debuginfod_client *" client ","  " const unsigned char *" build_id ","  " int " build_id_len ","  " char ** " path ");"  "int debuginfod_find_executable(debuginfod_client *" client ","  " const unsigned char *" build_id ","  " int " build_id_len ","  " char ** " path ");"  "int debuginfod_find_source(debuginfod_client *" client ","  " const unsigned char *" build_id ","  " int " build_id_len ","  " const char *" filename ","  " char ** " path ");" 
OPTIONAL FUNCTIONS

 "typedef int (*debuginfod_progressfn_t)(debuginfod_client *" client ","  " long a, long b);"  "void debuginfod_set_progressfn(debuginfod_client *" client ","  " debuginfod_progressfn_t " progressfn ");"  "void debuginfod_set_verbose_fd(debuginfod_client *" client ","  " int " fd ");"  "void debuginfod_set_user_data(debuginfod_client *" client ","  " void *" data ");"  "void* debuginfod_get_user_data(debuginfod_client *" client ");"  "const char* debuginfod_get_url(debuginfod_client *" client ");"  "int debuginfod_add_http_header(debuginfod_client *" client ","  " const char* " header ");" 
 DESCRIPTION
 debuginfod_begin () creates a debuginfod_client connection handle that should be used
with all other calls.
 debuginfod_end () should be called on the client handle to release all state and
storage when done.

 debuginfod_find_debuginfo (),  debuginfod_find_executable (), and
 debuginfod_find_source () query the debuginfod server URLs contained in
 $DEBUGINFOD_URLS (see below) for the debuginfo, executable or source file with the
given build_id. build_id should be a pointer to either
a null-terminated, lowercase hex string or a binary blob. If
build_id is given as a hex string, build_id_len should
be 0. Otherwise build_id_len should be the number of bytes in
the binary blob.

 debuginfod_find_source () also requires a filename in order to specify a particular
source file. filename should be an absolute path that includes
the compilation directory of the CU associated with the source file.
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: 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.

If path is not NULL and the query is successful, path is set
to the path of the file in the cache. The caller must free() this value.

The URLs in $DEBUGINFOD_URLS may be queried in parallel. As soon
as a debuginfod server begins transferring the target file all of the
connections to the other servers are closed.

A client handle should be used from only one thread at a time.

 "RETURN VALUE"
debuginfod_begin returns the debuginfod_client handle to
use with all other calls. On error NULL will be returned and
errno will be set.

If a find family function is successful, the resulting file is saved
to the client cache and a file descriptor to that file is returned.
The caller needs to close() this descriptor. Otherwise, a
negative error code is returned.

 "OPTIONAL FUNCTIONS"
A small number of optional functions are available to tune or query
the operation of the debuginfod client.

 "PROGRESS CALLBACK"
As the debuginfod_find_*() functions may block for seconds or
longer, a progress callback function is called periodically, if
configured with
 debuginfod_set_progressfn (). This function sets a new progress callback function (or NULL) for the
client handle.

The given callback function is called from the context of each thread
that is invoking any of the other lookup functions. It is given two
numeric parameters that, if thought of as a numerator a and
denominator b, together represent a completion fraction
a/b. The denominator may be zero initially, until a quantity
such as an exact download size becomes known.

The progress callback function is also the supported way to
interrupt the download operation. (The library does not
modify or trigger signals.) The progress callback must return 0 to
continue the work, or any other value to stop work as soon as
possible. Consequently, the debuginfod_find_*() function will
likely return with an error, but might still succeed.

 "VERBOSE OUTPUT"
The debuginfod_find_*() functions may use several techniques
to retrieve the requested files, through the cache or through one
or multiple servers or file URLs. To show how a query is handled the
 debuginfod_set_verbose_fd () can be used to set a particular file descriptor on which verbose
output is given about the query steps and eventual errors encountered.

 "USER DATA POINTER"
A single void * pointer associated with the connection handle
may be set any time via
 \%debuginfod_set_user_data () , and retrieved via
 \%debuginfod_get_user_data () . The value is undefined if unset.

 "URL"
The URL of the current or most recent outgoing download, if known,
may be retrieved via
 \%debuginfod_get_url () from the progressfn callback, or afterwards. It may be NULL.
The resulting string is owned by the library, and must not be modified
or freed. The caller should copy it if it is needed beyond the release
of the client object.

 "HTTP HEADER"
Before a lookup function is initiated, a client application may
add HTTP request headers to future downloads.
 \%debuginfod_add_http_header () may be called with strings of the form
 \%"Header:\~value" . These strings are copied by the library. A zero return value
indicates success, but out-of-memory conditions may result in
a non-zero -ENOMEM. If the string is in the wrong form
-EINVAL will be returned.

Note that the current debuginfod-client library implementation uses
libcurl, but you shouldn't rely on that fact. Don't use this function
for replacing any standard headers, except for the User-Agent mentioned
below. The only supported usage of this function is for adding an
optional header which might or might not be passed through to the
server for logging purposes only.

By default, the library adds a descriptive User-Agent:
header to outgoing requests. If the client application adds
a header with the same name, this default is suppressed.

 "CACHE"
If the query is successful, the debuginfod_find_*() functions save
the target file to a local cache. The location of the cache is controlled
by the $DEBUGINFOD_CACHE_PATH environment variable (see below).
Cleaning of the cache is controlled by the cache_clean_interval_s
and max_unused_age_s files, which are found in the
$DEBUGINFOD_CACHE_PATH directory. cache_clean_interval_s controls
how frequently the cache is traversed for cleaning and max_unused_age_s
controls how long a file can go unused (fstat(2) atime) before it's
removed from the cache during cleaning. These files should contain only an
ASCII decimal integer representing the interval or max unused age in seconds.
The default is one day and one week, respectively. Values of zero mean "immediately".

 "MACROS"
 "DEBUGINFOD_SONAME"
Defined to the string that could be passed to
 dlopen (3) if the library is loaded at runtime, for example


.EX
void *debuginfod_so = dlopen(DEBUGINFOD_SONAME, RTLD_LAZY);


 "SECURITY"
 debuginfod_find_debuginfo (),  debuginfod_find_executable (), and
 debuginfod_find_source () do not include any particular security
features. They trust that the binaries returned by the debuginfod(s)
are accurate. Therefore, the list of servers should include only
trustworthy ones. If accessed across HTTP rather than HTTPS, the
network should be trustworthy. Passing user 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 front-end
proxy server could.)

 "ENVIRONMENT VARIABLES"
 21
 DEBUGINFOD_URLS This environment variable contains a list of URL prefixes for trusted
debuginfod instances. Alternate URL prefixes are separated by space.

 21
 DEBUGINFOD_TIMEOUT This environment variable governs the timeout for each debuginfod HTTP
connection. A server that fails to provide at least 100K of data
within this many seconds is skipped. The default is 90 seconds. (Zero
or negative means "no timeout".)

 21
 DEBUGINFOD_PROGRESS This environment variable governs the default progress function. If
set, and if a progressfn is not explicitly set, then the library will
configure a default progressfn. This function will append a simple
progress message periodically to stderr. The default is no progress
function output.

 21
 DEBUGINFOD_VERBOSE This environment variable governs the default file descriptor for
verbose output. If set, and if a verbose fd is not explicitly set,
then the verbose output will be produced on STDERR_FILENO.

 21
 DEBUGINFOD_CACHE_PATH This environment variable governs the location of the cache where
downloaded files are kept. It is cleaned periodically as this
program is reexecuted. If XDG_CACHE_HOME is set then
$XDG_CACHE_HOME/debuginfod_client is the default location, otherwise
$HOME/.cache/debuginfod_client is used.


 "ERRORS"
The following list is not comprehensive. Error codes may also
originate from calls to various C Library functions.


 EACCESS Denied access to resource located at the URL.


 ECONNREFUSED Unable to connect to remote host. Also returned when an HTTPS connection
couldn't be verified (bad certificate).


 ECONNRESET Unable to either send or receive network data.


 EHOSTUNREACH Unable to resolve remote host.


 EINVAL One or more arguments are incorrectly formatted. build_id may
be too long (greater than 256 characters), filename may not
be an absolute path or a debuginfod URL is malformed.


 EIO Unable to write data received from server to local file.


 EMLINK Too many HTTP redirects.


 ENETUNREACH Unable to initialize network connection.


 ENOENT Could not find the resource located at URL. Often this error code
indicates that a debuginfod server was successfully contacted but
the server could not find the target file.


 ENOMEM System is unable to allocate resources.


 ENOSYS $DEBUGINFOD_URLS is not defined.


 ETIME Query failed due to timeout. $DEBUGINFOD_TIMEOUT controls
the timeout duration. See debuginfod(8) for more information.

 "FILES"

 .1v
 20
 $HOME/.debuginfod_client_cache Default cache directory. If XDG_CACHE_HOME is not set then
$HOME/.cache/debuginfod_client is used.


 "SEE ALSO"
 "debuginfod(8)"