public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Guillem Jover <guillem@debian.org>, Luca Boccassi <bluca@debian.org>
Cc: devel@lists.fedoraproject.org,
	"SystemD Devel" <systemd-devel@lists.freedesktop.org>,
	debhelper@packages.debian.org, binutils@sourceware.org,
	"Lennart Poettering" <lennart@poettering.net>,
	debian-dpkg@lists.debian.org,
	"elfutils-devel@sourceware.org" <elfutils-devel@sourceware.org>,
	"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
Subject: Re: Storing package metadata in ELF objects
Date: Wed, 19 May 2021 16:58:40 +0200	[thread overview]
Message-ID: <ccaeb466dcf4aff31769c2894a35b6aa006b9720.camel@klomp.org> (raw)
In-Reply-To: <YKRZdimgktzMoGp5@thunder.hadrons.org>

Hi Guillem,

On Wed, 2021-05-19 at 02:19 +0200, Guillem Jover wrote:
> So this is where I guess I'm missing something. To be able to make
> sense of the coredumps there are two things that might end up being
> relevant, backtraces and source code. systemd-coredump might already
> emit a backtrace, and depending on the information provided it might
> be more or less useful. If one needs the actual debug symbols there's
> already some external querying/fetching required, and if distribution
> specific source code is required because many distributions patch
> upstream source, then even more querying/fetching will be required.
> 
> Which is why I'm not seeing why this standalone and isolated metadata
> would be of much help by itself. As in, the way I see it, either the
> information from systemd (w/o the extra metadata) is sufficient to
> track down bugs, or that querying/fetching would be needed anyway, at
> which point the metadata can be inferred too then?

Because without that metadata you cannot easily figure out where/how to
get the files needed to properly track down the bugs. But using that
metadata you can figure out where the debuginfod server is that can
provide all that information for the binaries/core files (or a distro
specific method if the distributor doesn't have a debuginfod server
yet).

> Oh, I was thinking about those mixed environments, full chroots or
> stripped down containers, from different vendors, but affecting Debian
> installations. What I'm also probably missing here is how does the
> metadata help for a third-party that is not expected to track/keep/upload
> debug symbols nor source packages into some repository, because otherwise
> I'm not seeing how they'd make use of the cores (if they are insufficient
> by themselves) to debug issues? I guess my question back would be what
> would they do with the metadata if they do not have the debug symbols
> nor the sources readily available? Also assuming of course they exercise
> good practices such as never reusing the same package-version-arch tuple
> for different builds, and similar. :)

Different builds will have different build-ids, so they can be kept
apart. But even if without the distributor having added debuginfod
meta-data and providing a server to fetch the extra symbols, debuginfo,
sources, the extra meta-data is useful to administrators. Just seeing
that crashes are associated with specific distro/version/packages helps
narrow down instabilities.

Cheers,

Mark

  reply	other threads:[~2021-05-19 14:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-10 12:29 Luca Boccassi
2021-04-10 12:38 ` Luca Boccassi
2021-04-10 18:44   ` Zbigniew Jędrzejewski-Szmek
2021-04-30 17:57     ` Mark Wielaard
2021-05-04 13:43       ` Luca Boccassi
2021-05-06  1:17         ` Mark Wielaard
2021-05-06 11:43           ` Luca Boccassi
2021-05-14 10:41   ` Guillem Jover
2021-05-14 13:41     ` Luca Boccassi
2021-05-19  0:19       ` Guillem Jover
2021-05-19 14:58         ` Mark Wielaard [this message]
2021-05-24 10:17           ` Luca Boccassi

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=ccaeb466dcf4aff31769c2894a35b6aa006b9720.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=binutils@sourceware.org \
    --cc=bluca@debian.org \
    --cc=debhelper@packages.debian.org \
    --cc=debian-dpkg@lists.debian.org \
    --cc=devel@lists.fedoraproject.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=guillem@debian.org \
    --cc=lennart@poettering.net \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=zbyszek@in.waw.pl \
    /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).