On Mon, May 8, 2023, at 8:33 AM, Serhei Makarov wrote:
> Usage instructions will be kept up-to-date in README.eu-stacktrace on
> the topic branch:
>
> -
> https://sourceware.org/cgit/elfutils/tree/README.eu-stacktrace?h=users/serhei/eu-stacktrace
Hello,
I wanted to send an up-to-date outline of my current plans for eu-stacktrace. I
believe that I will be able to submit my branch for review prior to the planned
autumn release of elfutils. But there are still a number things to fix before
the code can go through formal review. For now I'll describe what these are
(and follow-up with another email once I've made good progress on them).
* Major features needed: basic support for perf tool.
The currently-implemented sysprof backend depends on a set of patches to
sysprof. I will submit these for review after a bit more code cleanup, but to
avoid creating a rigid timeframe for their release, it would be good to give
eu-stacktrace another use-case, even if only a basic one. Unwinding of stack
samples in perf tool recordings should be ideal for this.
* Major features needed(?): container support.
The timeframe for this is a bit more uncertain, but it's highly requested by
the sysprof maintainers; necessary for profiling Fedora Silverblue-type
systems. Sysprof currently includes code (e.g. in
src/libsysprof/sysprof-podman.c, sysprof-linux-instrument.c) to locate
executables inside podman and flatpak containers.
The extent to which this functionality needs to be replicated is still a bit
uncertain to me -- it may turn out that, for the elfutils reporting
infrastructure's purposes, access through the /proc/PID/{maps,mem} interface
will give us sufficient access to CFI.
But if it turns out to be needed, I'm not ruling out re-implementing the
Sysprof functionality for elfutils, because any benefits would accrue to any
tool that uses elfutils reporting. This would need to be reviewed as a separate
patchset since these would be changes to the elfutils libraries rather than a
separate new tool under src/.
* Various other fixes.
The major remaining issues to fix relate to architecture portability, and I
have a very good precedent here in terms of the perfparser implementation from
qt-creator cf.
https://codereview.qt-project.org/gitweb?p=qt-creator/perfparser.git;a=blob;f=app/perfregisterinfo.cpp;hb=HEAD
Beyond that, there is a certain amount of work to look at specific isolated
cases where eu-stacktrace isn't unwinding a particular application. Some of
these will lead to crucial bugfixes; others (such as tracing JIT
implementations that don't really worry about debuginfo) are not something we
can do much about. I would suggest that, once the abovementioned tasks are
done, it's best to release eu-stacktrace as an experimental tool and give more
people opportunity to 'kick the tires' and find more issues. A certain length
of time with the tool released as part of elfutils and continuing to mature is
really a prerequisite to start talking about eu-stacktrace as a reason to
re-enable framepointer optimizations.
All the best,
Serhei
