From: Milian Wolff <mail@milianw.de>
To: elfutils-devel@sourceware.org
Subject: Re: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API]
Date: Wed, 06 Jul 2022 20:28:22 +0200 [thread overview]
Message-ID: <5959578.lOV4Wx5bFT@agathemoarbauer> (raw)
In-Reply-To: <2782414.8Vx5aUIOYe@milian-workstation>
[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]
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
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5272 bytes --]
next prev parent reply other threads:[~2022-07-06 18:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 12:44 Questions regarding debuginfod.h API Milian Wolff
2022-04-08 13:44 ` Frank Ch. Eigler
2022-04-08 19:09 ` Milian Wolff
2022-04-08 19:44 ` Frank Ch. Eigler
2022-04-08 19:50 ` Milian Wolff
2022-04-09 13:44 ` Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API] Milian Wolff
2022-07-06 18:28 ` Milian Wolff [this message]
2022-07-06 18:40 ` Frank Ch. Eigler
2022-07-06 19:37 ` Milian Wolff
2022-07-06 19:41 ` Frank Ch. Eigler
2022-07-06 19:44 ` Milian Wolff
2022-07-06 19:54 ` Frank Ch. Eigler
2022-04-16 15:03 ` Questions regarding debuginfod.h API Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5959578.lOV4Wx5bFT@agathemoarbauer \
--to=mail@milianw.de \
--cc=elfutils-devel@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).