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 m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
