From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41797 invoked by alias); 5 Jul 2019 19:20:16 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 41782 invoked by uid 89); 5 Jul 2019 19:20:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=shipping, talk X-HELO: mail-vk1-f180.google.com Received: from mail-vk1-f180.google.com (HELO mail-vk1-f180.google.com) (209.85.221.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Jul 2019 19:20:15 +0000 Received: by mail-vk1-f180.google.com with SMTP id b200so1364044vkf.10 for ; Fri, 05 Jul 2019 12:20:14 -0700 (PDT) MIME-Version: 1.0 References: <20190705160455.GH4777@wildebeest.org> In-Reply-To: <20190705160455.GH4777@wildebeest.org> From: Aaron Merey Date: Fri, 05 Jul 2019 19:20:00 -0000 Message-ID: Subject: Re: debuginfo server progress update To: Mark Wielaard Cc: elfutils-devel@sourceware.org, systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q3/txt/msg00007.txt.bz2 Hi Mark, On Fri, Jul 5, 2019 at 12:46 PM Mark Wielaard wrote: > > 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 l= ookups > > 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=3Delfutils.git;a=3Dshortlog;h=3Drefs/heads/= dbgserver > > > The > > http web server itself is able to scan a directory tree for any debugin= fo, > > executable and source files and index them by build-id. The elfutils cl= ient > > hooks into libdwfl and provides a fallback so that if the library is no= t able > > to locate a debuginfo file, the client, if enabled, will attempt to que= ry > > debuginfo servers for debuginfo containing a particular build-id. > > [...] > > This time systemtap successfully acquires the debuginfo and begins runn= ing > > 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 p= lanned > > include a gdb client that could query debuginfo servers for debuginfo o= r source > > code and the ability for the server to automatically search rpms for an= y of the > > files requested by a client. We also are planning a talk/demo at GNU Ca= uldron > > this September in Montr=C3=A9al, Canada (https://gcc.gnu.org/wiki/cauld= ron2019). > > > > 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 apprecia= ted! > > 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 > and just open the resulting file. I really like this suggestion, even with just elfutils and gdb clients there will already be too much code duplication if we don't have the client code in it= s own binary. This raises questions such as whether dbgclient should be a shared library or a command line tool, but regardless of these implementation deta= ils you bring up an issue that needs to be addressed as the client side of debu= ginfo server grows. I appreciate the feedback! Aaron