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.
