eu-stacktrace: roadmap update

[Serhei Makarov]

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