On Freitag, 8. April 2022 15:44:32 CEST Frank Ch. Eigler wrote:
> Hi -

<snip>

> > Now to my question: In applications using elfutils, we will now
> > automatically download debug information when DEBUGINFOD_URLS is
> > defined. But doing that can take a very long time.
> 
> (See also the DEBUGINFOD_MAXTIME and DEBUGINFOD_MAXSIZE env vars
> that can limit this.)

I did come across those, but what are suggested best practices in setting 
those? When using GDB or a profiler on larger non-trivial UI applications on 
Linux for the first time, we would start to download dozens of debug packages, 
taking hundreds of megabytes of space. This simply takes time (in total), 
whereas the two environment variables above would be per-library, no? And 
usually one does not know a priori which libraries one needs - the size is not 
really a good criterium to decide whether to download a libraries debug 
information or not...

I'm not really complaining here - just thinking out loud. I believe for novice 
users the status quo is acceptable - they'll just need to wait for the 
download to finish (potentially taking minutes). More advanced users may want 
to manually skip some (larger) libs that they know they won't use for whatever 
they are looking at...

> > I would like to give the user feedback about this situation and
> > ideally provide a means to cancel the download.
> 
> OK.
> 
> > Looking at `debuginfod.h` I `debuginfod_set_progressfn` which looks
> > ideal. But how do I access the default `debuginfod_client *` which
> > seems to exist without me ever calling `debuginfod_begin` anywhere?
> > Or do I need to create a new client here via `debuginfod_begin`?
> 
> You do need to create a new client object.  You can reuse it.

Will the default code that uses debuginfod from within dwfl then pick up my 
new client object and use that? I feel like there's a fundamental confusion 
about this on my side about this. More on that at the end of this mail below.

> > Then, how would I cancel an ongoing download job? GDB seems to do
> > that when I press `CTRL+C`, but I do not see any API I could use for
> > that purpose?
> 
> See [man debuginfod_set_progressfn].  The return code from that
> progressfn callback is the ticket.

```
$ man debuginfod_set_progressfn
No manual entry for debuginfod_set_progressfn
```

My `debuginfod.h` also does not show any (useful) inline API documentation for 
most of that file. Could this please be improved? The doxygen for dwfl is 
great and can be read directly together with the code, I never used `man` for 
that purpose in the past?

> > Finally, what is the recommended way to check whether debuginfod is
> > available?  Should one rely on the build system to discover the
> > `debuginfod.h` header file, or is some other compile time check
> > suggested to detect it?  [...]
> 
> To decide whether or not to compile in support, you'd need a
> compile-time check such as for the debuginfod.h header.  (Alternately,
> you could opt not to compile in support at all, and instead call out
> to the debuginfod-find(1) program.)  To decide at run time whether or
> not to use it, you could just use the *_find APIs and get back an
> error code if things are not set up.  Or you can check the
> DEBUGINFOD_URLS for being set/unset before you call in.

I don't see where I would use debuginfod-find or any of the 
`debuginfod_find_*` API directly. I'm using dwfl which uses debuginfod 
internally. I guess that happens via the `dwfl_*find_*` standard callbacks 
provided in `libdwfl.h`. That works perfectly fine. I simply want a bit more 
control over the debuginfod usage that happens internally in dwfl.

Is maybe a `debuginfod_client *dwfl_debuginfod(void)` function missing that 
gives access to the client used by dwfl internally?

Thanks
-- 
Milian Wolff
mail@milianw.de
http://milianw.de