The /sysroot/ convention is something we see on OSTree-based systems
such as Silverblue or CoreOS which contains the running image. We can
skip that part of the path so that symbol resolving continues as normal.
We are starting to come into a situation where we need more advanced
path translations because we keep having to do things like this. Until
Linux figures out file-system namespaces at a higher level at least.
Really what we want to deal with here is tracking an overlay that we may
need to be able to decode after the fact (in case processes exit or we
need to do post-processing symbol resolution).
For the podman case, that is $some_path mapped to root (/), generally
speaking. For flatpak though, that would have two mappings, one for
/app and another for /usr (possibly more).
We want to know the location of our root if it was specified in the
capture file. Such is useful for decoding symbols that may not be
reported right from perf tooling.
This allows us to try to translate maps for processes in containers.
For processes we find in a podman container, we can sniff the libpod
cgroup scope. Using that we can translate into the podman layer that
contains the files.
With that, future work could find the proper .so when resolving based on
alternate roots for the process.
While I'm not thrilled to add new frame types for every sort of thing, I
think having this will be relatively useful so we can improve decoding
operations.
This adds SysprofCapturePidRoot which lets us specify a root directory
on the host system for which is the real root (/) of the PID. This can
be useful when reconstructing overlays for containers and you need to
direct access to alternate roots.
The layer gives us some ability to try to deal with overlayfs, albeit at
a very rudimentary level. In most cases I anticipate we just deal with
the main root and ignore overlays until necessary.
It turns out that /proc/cpuinfo changes out from under us rather frequently
and that makes it a bad use-case for a unit test. This uses meson.build
which presumably wont change while running the tests.
This helps some annoying cases where we keep checking over and over for
each CPU, procfile, etc during startup.
It makes the tool less useful on systems without D-Bus, but let's be
honest, profiling is a Linux only game for Sysprof.
