Re: eu-stacktrace: roadmap and discussion thread

[Christian Hergert <chergert@redhat.com>]

First off, this all sounds great!

I'm not on the mailing list, so apologies if this takes extra-effort to 
show up there.

On 5/8/23 5:33 AM, Serhei Makarov wrote:
> eu-stacktrace will be a utility to process a stream of raw stack
> samples (such as those obtained from the Linux kernel's
> PERF_SAMPLE_STACK facility) into a stream of stack traces (such as the
> ones obtained from PERF_SAMPLE_CALLCHAIN), freeing various profiling
> utilities from having to implement their own backtracing logic.

 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.

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.

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?

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.

Thanks again for all your work on this, I'm very excited to see what we 
can come up with!

-- Christian