Will eu-addr2line support debuginfod?

Will eu-addr2line support debuginfod?

[Vitaly Chikunov]

Hi,

Is it planned to have eu-addr2line supporting debuginfod? I try to
pass '[build-id]@address' (in the same format that eu-stack outputting)
without success:

  # eu-stack -b -p 1
  PID 1 - process
  TID 1:
  #0  0x00007ffa8d4c2886 epoll_wait
      [c017df57d6194b6479cef409cba575bbaa537c94]@0x7ffa8d3c5000+0xfd886
  ...
  $ export DEBUGINFOD_URLS=...
  $ eu-addr2line '[c017df57d6194b6479cef409cba575bbaa537c94]@0x7ffa8d3c5000+0xfd886'
  eu-addr2line: a.out: No such file or directory
  $

Thanks,

ps. Additionally, I think, it would be extra cool to have addr2line request
functionality added to debuginfod protocol. For example, to request like:
'/buildid/123..DEF/addr2line/@0x7ffa8d3c5000+0xfd886'. Our experiments
show, that to generate KDE stack traces via debuginfod requires
gigabytes of traffic (downloading uncompressed .debug binary), which is
many times more than installing (lzma compressed) -debuginfod .rpm file.
Where, several remote addr2line requests would do the job.

Re: Will eu-addr2line support debuginfod?

[Frank Ch. Eigler]

Hi, Vitaly -

> Is it planned to have eu-addr2line supporting debuginfod? I try to
> pass '[build-id]@address' (in the same format that eu-stack outputting)
> without success [...]

For a broader discussion of the same topic, see:
     https://sourceware.org/bugzilla/show_bug.cgi?id=25793
I remain of the opinion that all elfutils tools should automagically
attempt debuginfod queries, if they encounter incomplete data.

If we cannot overcome objections to that, we may end up having to
invent a new elfutils tool that does general elf/dwarf dumping.


> ps. Additionally, I think, it would be extra cool to have addr2line request
> functionality added to debuginfod protocol. For example, to request like:
> '/buildid/123..DEF/addr2line/@0x7ffa8d3c5000+0xfd886'. 

Yes, adding higher level query operations to the webapi was in mind
right from the beginning of the project.  It's a matter of tasteful
API design, analysis of other candidate client tools.  I'd search for
inspiration from, maybe those very same dumping tools contemplated by
PR25793 and maybe complex tools like systemtap/gdb, and general query
tools like dwgrep.  A lot of work to do.
 

> Our experiments show, that to generate KDE stack traces via
> debuginfod requires gigabytes of traffic (downloading uncompressed
> .debug binary), which is many times more than installing (lzma
> compressed) -debuginfod .rpm file.  Where, several remote addr2line
> requests would do the job.

You're right, debuginfod itself does not compress on its webapi - it
ignores the Accept-Encoding request header.  On a LAN-nearby server,
that doesn't make any difference really.  On a remote server, one
should probably set up a reverse-proxy front-end such as httpd or
nginx that does support compressed encodings, such as all of the
public servers listed at
https://sourceware.org/elfutils/Debuginfod.html .  The debuginfod
client will happily receive compressed-encoding responses from such
servers.

We could also entertain teaching debuginfod itself to compress on the
fly.  It's just a more tricky use of the libmicrohttpd apis.

- FChE

Re: Will eu-addr2line support debuginfod?

[Mark Wielaard]

Hi,

On Tue, 2020-12-01 at 10:23 -0500, Frank Ch. Eigler via Elfutils-devel
wrote:
> Is it planned to have eu-addr2line supporting debuginfod? I try to
> > pass '[build-id]@address' (in the same format that eu-stack
> > outputting)
> > without success [...]
> 
> For a broader discussion of the same topic, see:
>      https://sourceware.org/bugzilla/show_bug.cgi?id=25793
> I remain of the opinion that all elfutils tools should automagically
> attempt debuginfod queries, if they encounter incomplete data.
> 
> If we cannot overcome objections to that, we may end up having to
> invent a new elfutils tool that does general elf/dwarf dumping.

I think that is a different discussion.
eu-addr2line and eu-stack will already query a debuginfod server when
DEBUGINFOD_URLS is set (and the debuginfo isn't already available
locally).

The discussion about eu-readelf is that the utility itself doesn't
really deal with DWARF except that it dumps the data contents of
sections containing DWARF. We could introduce an option like binutils
has, --debug-dump=follow-links, which could drop. This would be
somewhat like the current --debug-dump=info+ which follows links to
split DWARF files. I just don't understand (or maybe I do, but don't
like) the semantics of --debug-dump=follow-links. It seems somewhat
imprecise and arbitrary IMHO.

The question is whether eu-addr2line could accept a new kind of address
specification that include the build-id like how eu-stack -b produces
output.

I guess we could, but is that really something people would use?
eu-stack -b shows module build-id, load address and pc offset. Which
can be mapped back to the actual (relative address) inside the build-
id.

Is '[c017df57d6194b6479cef409cba575bbaa537c94]@0x7ffa8d3c5000+0xfd886'
really something people want to query eu-addr2line about? We would
basically throw away the load address, and just use build-id + offset.
So something like c017df57d6194b6479cef409cba575bbaa537c94+0xfd886
would be fine.

If you think something like that is useful, then please do open a bug
report https://sourceware.org/bugzilla/enter_bug.cgi?product=elfutils

Thanks,

Mark

debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?

[Vitaly Chikunov]

Hi,

On Tue, Dec 01, 2020 at 10:23:30AM -0500, Frank Ch. Eigler wrote:
> We could also entertain teaching debuginfod itself to compress on the
> fly.  It's just a more tricky use of the libmicrohttpd apis.

Btw, JFYI, we have in ALT Linux our own debuginfod implementation (two
scripts in ruby based on man debuginfod(8) protocol description) since 27
Nov 2020. Maybe it would be useful to know there is alternative
implementations too.

Thanks,

Re: debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?

[Frank Ch. Eigler]

Hi -

> On Tue, Dec 01, 2020 at 10:23:30AM -0500, Frank Ch. Eigler wrote:
> > We could also entertain teaching debuginfod itself to compress on the
> > fly.  It's just a more tricky use of the libmicrohttpd apis.
> 
> Btw, JFYI, we have in ALT Linux our own debuginfod implementation (two
> scripts in ruby based on man debuginfod(8) protocol description) since 27
> Nov 2020. Maybe it would be useful to know there is alternative
> implementations too.

Sure, would be glad to link to it, if you send us a URL to the docs/code
and/or server itself.


- FChE

Re: debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?

[Vitaly Chikunov]

Frank,

On Tue, Apr 13, 2021 at 02:22:32PM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> > On Tue, Dec 01, 2020 at 10:23:30AM -0500, Frank Ch. Eigler wrote:
> > > We could also entertain teaching debuginfod itself to compress on the
> > > fly.  It's just a more tricky use of the libmicrohttpd apis.
> > 
> > Btw, JFYI, we have in ALT Linux our own debuginfod implementation (two
> > scripts in ruby based on man debuginfod(8) protocol description) since 27
> > Nov 2020. Maybe it would be useful to know there is alternative
> > implementations too.
> 
> Sure, would be glad to link to it, if you send us a URL to the docs/code
> and/or server itself.

Public server https://debuginfod.altlinux.org/
Announcement https://lists.altlinux.org/pipermail/devel/2020-November/212756.html
Wiki page that mentions it https://www.altlinux.org/Debuginfo (in
Russian).

Server code was not intended to be a community project, so the changelog
is a bit ashaming in it's tersity and granularity
  http://git.altlinux.org/people/vt/private/debuginfer.git

Thanks,

Re: debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?

[Frank Ch. Eigler]

Hi -

> Public server https://debuginfod.altlinux.org/
> Announcement https://lists.altlinux.org/pipermail/devel/2020-November/212756.html

Ah neat!  Added a link to this onto our project page.

- FChE

Re: debuginfod in ALT linux Ex:Re: Will eu-addr2line support debuginfod?

[Vitaly Chikunov]

Frank,

On Wed, Apr 14, 2021 at 01:10:45PM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> > Public server https://debuginfod.altlinux.org/
> > Announcement https://lists.altlinux.org/pipermail/devel/2020-November/212756.html
> 
> Ah neat!  Added a link to this onto our project page.

Thanks! It may be added to the empty cells, packages "all" and
architectures "x86_64, i586, aarch64, armh, ppc64le".

Vitaly,


> 
> - FChE