public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Milian Wolff <mail@milianw.de>
Cc: elfutils-devel@sourceware.org
Subject: Re: Questions regarding debuginfod.h API
Date: Fri, 8 Apr 2022 15:44:32 -0400	[thread overview]
Message-ID: <20220408194432.GB23295@redhat.com> (raw)
In-Reply-To: <12359040.Dq0kRfdbeh@milian-workstation>

Hi -

> > (See also the DEBUGINFOD_MAXTIME and DEBUGINFOD_MAXSIZE env vars
> > that can limit this.)

> I did come across those, but what are suggested best practices in
> setting those? When using GDB or a profiler on larger non-trivial UI
> applications on Linux for the first time, we would start to download
> dozens of debug packages, taking hundreds of megabytes of
> space. [...]

Yes, and each of those downloads can be limited by these criteria.  An
application such as gdb could adds its own throttling on top, if it is
going to do a long series of downloads.  (Alternately, gdb can try not
to download all this stuff early; we're investigating gdbindex-only
fetch operations.)


> > > Looking at `debuginfod.h` I `debuginfod_set_progressfn` which looks
> > > ideal. But how do I access the default `debuginfod_client *` which
> > > seems to exist without me ever calling `debuginfod_begin` anywhere?
> > > Or do I need to create a new client here via `debuginfod_begin`?
> > 
> > You do need to create a new client object.  You can reuse it.
> 
> 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.


> ```
> $ man debuginfod_set_progressfn
> No manual entry for debuginfod_set_progressfn
> ```

Well go complain to your distro for this packaging bug. :-)
It's an alias of [man debuginfod_find_debuginfo].


> My `debuginfod.h` also does not show any (useful) inline API
> documentation for most of that file. Could this please be improved?
> The doxygen for dwfl is great and can be read directly together with
> the code, 

As they say, patches welcome. :-) The header contains some curt
comments documenting each function.

> I never used `man` for that purpose in the past?

There is a whole section of POSIX man pages for API docs: 3.


- FChE


  reply	other threads:[~2022-04-08 19:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 12:44 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 [this message]
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
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=20220408194432.GB23295@redhat.com \
    --to=fche@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mail@milianw.de \
    /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).