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?

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