public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "Serhei Makarov" <serhei@serhei.io>
To: "Christian Hergert" <chergert@redhat.com>,
	builder--- <elfutils-devel@sourceware.org>
Cc: "Frank Ch. Eigler" <fche@elastic.org>, "Mark Wielaard" <mark@klomp.org>
Subject: Re: eu-stacktrace: roadmap and discussion thread
Date: Thu, 11 May 2023 15:27:50 -0400	[thread overview]
Message-ID: <5e4a77d5-43ec-4ecc-918f-b3dd0e830c4c@app.fastmail.com> (raw)
In-Reply-To: <cc291ab1-9e13-629c-5893-a2f7e0acb81a@redhat.com>

On Mon, May 8, 2023, at 5:50 PM, Christian Hergert wrote:
> First off, this all sounds great!
> ...
>
>  From a consumption standpoint, it would be nice if Sysprof could get a 
> perf stream where the PERF_SAMPLE_STACK are transparently converted to 
> PERF_SAMPLE_CALLCHAIN. I don't think eu-stacktrace necessarily needs to 
> speak Sysprof's capture API.
>...
>
> Sysprof already contains `sysprofd` which can open the Perf event stream 
> for us via d-bus/CAP_SYS_ADMIN/polkit integration. After Sysprof gets 
> the perf FD back from sysprofd we could spawn eu-stacktrace giving it 
> the FD to consume and another FD to write the translated/passthrough events.
The idea with sysprofd in the below quote sounds intriguing; I think we
can experiment with it once we have some perf parser code of our own.

For now, I'm satisfied with the fact that the patch to enable Sysprof to pipe
data to eu-stacktrace is very small, and the parsing code I'm working on
for separating out Sysprof capture frames is also quite small. Both are
easy to adapt to any refactoring or even data format changes you
might happen to do.

> Sysprof can do offline symbolizing of frames which is somewhat important 
> when trying to analyze profiles from an embedded device, a machine that 
> is disk/network constrained, or end-user-system via bug reports. We can 
> fairly trivially teach Sysprof to do symbolizing via debuginfod.
Yep -- and that could be a separate patchset, since the current approach
I'm using changes nothing about the Sysprof symbolizing phase.

> In the case you're describing, is it right that you may not be able to 
> unwind stack frames without debuginfod because there was no way to 
> locate the `.eh_frame` section for the binary?
Yep -- for containers, I considered debuginfod as a possible fallback
if the .eh_frame data isn't accessible on the local filesystem.
Of course that doesn't work for non-packaged container programs,
unless the developers of those programs set up debuginfod.
In general the workflows for debuginfo on containers are
rather under-developed.

Honestly this isn't a scenario to implement as a first priority,
but I do want to keep track of everything that's required
to have sysprof+eu_stacktrace+eh_frame+PERF_SAMPLE_STACK
maintain feature parity with sysprof+-fno-omit-fp+PERF_SAMPLE_CALLCHAIN.
Thus I am making sure to list such consideration.

> The code to do the mount namespace conversion is quite terrible in 
> Sysprof and even now I'm in the midst of cleaning it up. We have to both 
> create a "view" of the namespace as it was to the PID as well as a way 
> to convert that view into something the mount namespace analyzing the 
> capture file might be able to open. Any of these may or may not be in a 
> rootless container (toolbox/podman/flatpak/etc).
>
> Whether or not this is something we can eventually contain inside of 
> bubblewrap is another can of worms.
One possible solution....

For this type of situation, we could perhaps give eu-stacktrace an
optional dependency on sysprof-devel.

Right now, I rely on sysprof-capture-types.h but that's just the header
and therefore not a runtime dependency.

When the sysprof libraries are available, we could also use sysprof's
mount namespace conversion code (in whatever eventual form it takes)
to get .eh_frame data.

  reply	other threads:[~2023-05-11 19:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-08 12:33 Serhei Makarov
2023-05-08 21:50 ` Christian Hergert
2023-05-11 19:27   ` Serhei Makarov [this message]
2023-05-15 17:55     ` Christian Hergert
2023-05-09 18:02 ` Milian Wolff
2023-05-11 19:31   ` Serhei Makarov
2024-07-03 14:21 ` eu-stacktrace: roadmap update Serhei Makarov

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=5e4a77d5-43ec-4ecc-918f-b3dd0e830c4c@app.fastmail.com \
    --to=serhei@serhei.io \
    --cc=chergert@redhat.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@elastic.org \
    --cc=mark@klomp.org \
    /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).