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
next prev parent 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).