Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
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
Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
Hi -
> > 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);
> > ```
(Don't quite see how this extension would let you disable or enable
debuginfod support on a given dwfl. By the time a progressfn is
called, some debuginfod traffic would be attempted.)n
> Alternately:
> [...]
> > /* 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?
In order to -influence- things, would you not need to -change- the
client somehow? We don't have debuginfod-client apis to disable or
reconfigure any particular client object. Such an API wouldn't let
you replace it with a hook object of your own either.
So, dunno, could you perhaps remind us what your current usage
interests are?
To enable/disable it on a per-dwfl basis? If yes, and if statically,
maybe a new Dwfl_Callbacks option for .find_debuginfo() could be your
ticket: a dwfl_standard_find_debuginfo variant sans debuginfod at the
end.
- FChE
Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
On Mittwoch, 6. Juli 2022 20:40:09 CEST Frank Ch. Eigler wrote:
> Hi -
>
> > > 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);
> > >
> > > ```
>
> (Don't quite see how this extension would let you disable or enable
> debuginfod support on a given dwfl. By the time a progressfn is
> called, some debuginfod traffic would be attempted.)n
>
> > Alternately:
> > [...]
> >
> > > /* 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?
>
> In order to -influence- things, would you not need to -change- the
> client somehow? We don't have debuginfod-client apis to disable or
> reconfigure any particular client object. Such an API wouldn't let
> you replace it with a hook object of your own either.
>
>
> So, dunno, could you perhaps remind us what your current usage
> interests are?
>
> To enable/disable it on a per-dwfl basis? If yes, and if statically,
> maybe a new Dwfl_Callbacks option for .find_debuginfo() could be your
> ticket: a dwfl_standard_find_debuginfo variant sans debuginfod at the
> end.
I have two goals:
a) Notifying the user that a download is ongoing. Right now, it feels like the
tool is frozen as no feedback is given to the user.
b) Allow to disable debuginfod. But that is already doable by unsetting the
DEBUGINFOD_URLS env var, and as such I don't necessarily need any additional
API for that?
As such, only a) is something that needs immediate attention imo, and what my
API proposal is covering.
Thanks
--
Milian Wolff
http://milianw.de
Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
Hi - > a) Notifying the user that a download is ongoing. Right now, it feels like > the > tool is frozen as no feedback is given to the user. Right, can you explain how DEBUGINFOD_PROGRESS=1 is not a good fit in your case? - FChE
Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
On Mittwoch, 6. Juli 2022 21:41:33 CEST Frank Ch. Eigler wrote: > Hi - > > > a) Notifying the user that a download is ongoing. Right now, it feels like > > the tool is frozen as no feedback is given to the user. > > Right, can you explain how DEBUGINFOD_PROGRESS=1 is not a good fit in your > case? As you said yourself: > There is a > DEBUGINFOD_PROGRESS env var with which it can activate some > notification to stderr, but that's about it. I'm working on GUI applications (hotspot [1], gammaray [2]), people do not look at the command line output. I want to show the download progress and status graphically instead. [1]: https://github.com/KDAB/hotspot/ [2]: https://github.com/KDAB/gammaray -- Milian Wolff http://milianw.de
Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
Hi - > I'm working on GUI applications (hotspot [1], gammaray [2]), people do not > look at the command line output. I want to show the download progress and > status graphically instead. [...] Aha, got it. I'd say a extern debuginfod_client *dwfl_get_debuginfod_client (Dwfl *); type function would probably be your bet. That could also be built upon later, to provide finer grained control (to override environment variable settings e.g.). The other approach of a custom Dwfl_Callbacks .find_debuginfo hook is also available, wherein your own app can take charge of finding / downloading debuginfo, with its own bespoke debuginfod_client object. This would have the benefit of working with existing elfutils. - FChE
