On Freitag, 8. April 2022 21:44:32 CEST Frank Ch. Eigler wrote:
> Hi -
> 
> > > (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. [...]
> 
> Yes, and each of those downloads can be limited by these criteria.  An
> application such as gdb could adds its own throttling on top, if it is
> going to do a long series of downloads.  (Alternately, gdb can try not
> to download all this stuff early; we're investigating gdbindex-only
> fetch operations.)
> 
> > > > 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.
>
> Ah yes, I didn't realize you were talking about the hidden debuginfod
> client usage in libdwfl.  Yes, you have not much control over that,
> because it is ....  hidden & automatic.  There is a
> DEBUGINFOD_PROGRESS env var with which it can activate some
> notification to stderr, but that's about it.  No API to get at the
> internal transient objects.
> 
> If you wish to take control of this part, you could probably still use
> dwfl.  You would do all the debuginfod client API calls yourself, then
> "report" the dwarf file content to dwfl via dwarf_begin_elf(),
> dwarf_begin(), dwarf_setalt() etc.

OK thank you, that is helpful. Would you say adding dwfl API to get access to 
the internal debuginfod client would be a good path forward? I guess more 
projects would potentially like to benefit from the ready made integration, 
but add a bit of control on top of it?

> > ```
> > $ man debuginfod_set_progressfn
> > No manual entry for debuginfod_set_progressfn
> > ```
> 
> Well go complain to your distro for this packaging bug. :-)
> It's an alias of [man debuginfod_find_debuginfo].

Found it now - it's packaged together with `debuginfod`, even though it should 
be part of `elfutils`.

> > 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,
> 
> As they say, patches welcome. :-) The header contains some curt
> comments documenting each function.

Would you be OK with me simply copying over the contents from the man page 
over to doxygen? Or is there a better process in place to prevent such kind of 
documentation duplication? I would have expected that the man pages for API 
documentation are generated from e.g. doxygen which does not seem to be the 
case here?

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