patch 3/3 debuginfod client interruptability

Mark Wielaard mark@klomp.org
Fri Nov 15 17:35:00 GMT 2019


Hi Aaron,

On Fri, 2019-11-15 at 12:03 -0500, Aaron Merey wrote:
> On Fri, Nov 15, 2019 at 11:16 AM Mark Wielaard <mark@klomp.org> wrote:
> > On Mon, 2019-11-04 at 16:48 -0500, Frank Ch. Eigler wrote:
> > > At the wise counsel of gdb folks such as <tromey> and <simark>:
> > > 
> > >     debuginfod 3/3: client interruptability
> > > 
> > >     For interactive clients such as gdb, interruptibility is important for
> > >     usability during longer downloads.  This patchset adds a
> > >     download-progress callback function to the debuginfod client library,
> > >     with which a caller app can interrupt a download as well as be
> > >     notified of its quantitative progress.
> > 
> > I have some concerns about this. It cannot be associated with a
> > particular debuginfod-find request.
> 
> Good point, maybe we should add a progress function to debuginfo-find,
> or include a default progress function with libdebuginfod. Maybe one
> that prints the url where the target was found plus the download
> completion percentage every few seconds.
> 
> > IMHO it should have an extra argument to indicate which build-id
> > and request type exec, debug or source (+path) the progress/callback
> > was for.
> 
> I think we could add this information to the progress function output
> without changing the API. But if users would like more control over
> how this information gets used in the progress func maybe it's
> worth considering.
> 
> > Also this one global progress/interruptable hook. Which means it
> > cannot be used by e.g. libdw and an application that uses both
> > libdw and find-debuginfo directly.
> 
> I wonder how often this kind of situation will come up. If it's very
> infrequent maybe it's enough to simply flag this issue in the docs
> so users know to avoid it.

I think it is pretty common these days. People reuse libraries, which
use libraries themselves and more and more programs will use multiple
threads of execution.

IMHO it would be best to avoid any global state from the start. Since
we haven't released this api yet we can make it so that it is easy to
have state per request object. In the gdb thread 
https://sourceware.org/ml/gdb-patches/2019-11/msg00118.html Simon
Marchi suggested something like:

    debuginfod_client *client = debuginfod_create_client ();
    debuginfod_set_progressfn (client, my_progress_cb);

With debuginfod_client * being an opaque pointer. I think that is a
good idea. It also matches what libelf (with Elf *) and libdw (with
Dwarf *) do. It also makes it easy to add other kinds of state to
client requests later.

Cheers,

Mark



More information about the Elfutils-devel mailing list