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. > ``` > $ 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]. > 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. > I never used `man` for that purpose in the past? There is a whole section of POSIX man pages for API docs: 3. - FChE
