Re: debuginfo server progress update

[Mark Wielaard <mark@klomp.org>]

Hi Aaron,

On Wed, Jul 03, 2019 at 03:59:46PM -0400, Aaron Merey wrote:
> The debuginfo server, a web service that offers lightweight on-demand lookups
> of debuginfo-related data, along with its elfutils client have begun to take
> shape so I want to provide an update on where we currently are in its
> development and how to use it.
> 
> We plan on shipping debuginfo server with elfutils and it is currently
> available on the branch 'fche/dbgserver' of the elfutils git repo.

And now also simply on 'dbgserver'.
https://sourceware.org/git/?p=elfutils.git;a=shortlog;h=refs/heads/dbgserver

> The
> http web server itself is able to scan a directory tree for any debuginfo,
> executable and source files and index them by build-id. The elfutils client
> hooks into libdwfl and provides a fallback so that if the library is not able
> to locate a debuginfo file, the client, if enabled, will attempt to query
> debuginfo servers for debuginfo containing a particular build-id.
> [...]
> This time systemtap successfully acquires the debuginfo and begins running
> the probe. Although in this example everything is running locally, the server
> and the debuginfo could just as well be on a remote host.
> 
> Debuginfo server development is ongoing. Some of the features we have planned
> include a gdb client that could query debuginfo servers for debuginfo or source
> code and the ability for the server to automatically search rpms for any of the
> files requested by a client. We also are planning a talk/demo at GNU Cauldron
> this September in Montréal, Canada (https://gcc.gnu.org/wiki/cauldron2019).
> 
> Hopefully this helped give you a sense of how to use debuginfo server, where it
> is in its development, and what is to come. Feedback is always appreciated!

I think it would be nice if there was a dbgclient binary that could be
reused by multiple clients.  It could do most of what you currently do
in libdwfl/dbgserver-client.c. It would simply take a buildid and type
(exec, dbg, src) and return a file path to the resulting file when
found (or a well defined error number when not found).

Such a dbgclient executable would make writing other clients
easier. For example dbgserver_build_id_find would simply reduce to
spawning dbgclient with the right arguments and opening the resulting
file path. Other clients, like gdb, then also don't need to implement
the caching and quering, but can also simply call dbgclient <build-id>
<type> and just open the resulting file.

Cheers,

Mark