public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Aaron Merey <amerey@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH] debuginfod: Support queries for ELF/DWARF sections.
Date: Wed, 28 Sep 2022 14:20:11 -0400	[thread overview]
Message-ID: <CAJDtP-RDOAHT=EUsQ0ufyuAwUZk3R9P3AvZ-uH6gQC6JUC+K3w@mail.gmail.com> (raw)
In-Reply-To: <20220928142818.GH7916@redhat.com>

Hi Frank,

On Wed, Sep 28, 2022 at 10:28 AM Frank Ch. Eigler <fche@redhat.com> wrote:
> On Tue, Sep 27, 2022 at 10:10:52PM -0400, Aaron Merey via Elfutils-devel wrote:
>
> > [...]  In order to distinguish between debuginfo and executable
> > files with the same build-id, this function includes a bool
> > parameter use_debuginfo.  If true, attempt to retrieve the section
> > from the debuginfo file with the given build-id. If false, use the
> > executable instead.  [...]
>
> How would a client know which one to use?  Does it provide power or
> benefit to force them to choose (or iterate?).  Is there a scenario
> where the content could be different between the two (if both
> existed)?
>
> If that decisionmaking is not warranted to put upon the shoulders of
> the client, the server could just be asked for a section name "as if
> from an unstripped executable", and let it find that in the executable
> or debuginfo, whereever.

Good point, the server/client should figure this out internally.  On
IRC we also discussed the possible usefulness of client-side
emulation of section queries in case a server isn't built with
_find_section support.  Will update the patch to include these details.

> > [...] Although this patch does not implement it, we could generate
> > .gdb_index on-the-fly if the target file does not contain it.
> > However for large debuginfo files generating the index can take a
> > non-trivial amount of time (ex. about 25 seconds for a 2.5GB
> > debuginfo file).  [...]
>
> Even that is not too bad, considering that the alternative would be
> having to download that 2.5GB file.  I recall you saying that on some
> distros, gdb-index sections are always there anyway, so we wouldn't
> have to rush to implement this feature.

I did a quick experiment checking the debuginfo for the libraries used
by gdb, firefox and qemu-kvm on F36. Out of the 265 files I checked
only 1 (libicudata.so.69.1 debuginfo) didn't contain a .gdb_index
because it strangely does not contain any .debug_* sections at all.

Aaron


  reply	other threads:[~2022-09-28 18:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28  2:10 Aaron Merey
2022-09-28 14:28 ` Frank Ch. Eigler
2022-09-28 18:20   ` Aaron Merey [this message]
2022-10-21  0:06 [PATCH v2] " Aaron Merey
2022-10-22  0:09 ` [PATCH] " Aaron Merey
2022-10-24 18:38   ` Frank Ch. Eigler
2022-10-26 14:57     ` Mark Wielaard
2022-10-26 15:28       ` Frank Ch. Eigler
2022-10-26 17:57       ` Aaron Merey
2022-10-26 15:25     ` Mark Wielaard
2022-10-26 17:55     ` Aaron Merey

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='CAJDtP-RDOAHT=EUsQ0ufyuAwUZk3R9P3AvZ-uH6gQC6JUC+K3w@mail.gmail.com' \
    --to=amerey@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@redhat.com \
    /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).