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 m...@milianw.de http://milianw.de
smime.p7s
Description: S/MIME cryptographic signature
