On Samstag, 9. April 2022 15:44:34 CEST Milian Wolff wrote:
> On Freitag, 8. April 2022 21:50:18 CEST Milian Wolff wrote:
> > On Freitag, 8. April 2022 21:44:32 CEST Frank Ch. Eigler wrote:
> > > > 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?
> 
> I looked into this a bit more, and would like to expand the dwfl API to give
> more control over how it uses debuginfod internally.
> 
> Without any API changes, I currently can not disable debuginfod usage in
> dwfl. Well, the only option would be to unset the environment variable
> before any call into dwfl. But if I would roll my own debuginfod client
> code, it would still depend on the environment variable - thus the code
> would become quite ugly with repeated setenv/unsetenv pairs.
> 
> Additionally, the debuginfod client code in dwfl is good and well tested.
> Rolling my own just to get progress reporting and cancellation sounds like a
> waste of time to me.
> 
> Thus my proposal, and RFC:
> 
> ```
> /* Let us mirror the debuginfod progressfn for dwfl and forward it to
>    the internal debuginfod client, if available.
>    This way, dwfl's usage of debuginfod can stay optional and we would not
>    need to link to debuginfod directly from code using dwfl.
>  */
> typedef int (*dwfl_debuginfod_progressfn_t)(Dwfl *dwfl, long a, long b);
> extern void dwfl_set_debuginfod_progressfn(Dwfl *dwfl,
> 			           dwfl_debuginfod_progressfn_t fn);
> ```
> 
> This would already greatly help me. Better yet, we would eventually also add
> some more information to the progress callback, such as the name of the
> library that has triggered the download. But that could be done in a follow
> up patch, in a fashion similar to `debuginfod_get_url` I believe.
> 
> Alternatively:
> 
> ```
> /* We could just give full access to the internal client
>    but doing so may clash with future usages of e.g.
>    debuginfod_{set,get}_user_data in dwfl and users of dwfl.
>    Otherwise, this is obviously easiest and gives most flexibility.
>    We just need to forward get_client from debuginfod-client.c
>  */
> extern debuginfod_client *dwfl_debuginfod_client (Dwfl *);
> ```
> 
> What do you all think?

Ping, could I get some feedback on the above please? I have some time the next 
days and would like to work on this. Which way would you prefer?

Thanks

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