And include a fallback in case we never got an actual Process frame which
will contain the cmdline for the process. We need to hold onto the fallback
too so that we can keep symbols lightweight by not having to reference them
so long as the document is alive.
This allows us to avoid the function call overhead for each of the
instruction pointers in the stack trace. Instead let the interface handle
the decoding of the whole set.
If we have a build-id, we might find it in a path like the following:
/usr/lib/debug/.build-id/aa/aa123456789012345678901234567890
so do that lookup before we try to resolve the debuglink name.
In modern podman, we will get lowerdir= and upperdir= in the superblock
options which we can parse to find where things are on the host. Use that
instead of relying on overlay mounts.
Additionally, if we're on a subvolume, and that subvolume matches the
prefix of the root, then skip past that. I have no idea if this is the
right thing to do, but it's what we were doing before and seems to be
able to help us get proper path resolving on Silverblue.
I highly doubt this is foolproof, but this makes Silverblue more likely to
resolve the proper fstab entry when translating to paths we can access
from the host system.
If we fail to load a /proc/kallsyms.gz from the capture file, we can still
provide an "In Kernel+address" symbol. I prefer this to force loading the
kallsyms from the current system because that:
1. Requires privileged access and therefore means potentially an
authorization dialog.
2. May not even be from the same system that the capture was recorded
leading to incorrect symbolization.
This needs to process the debug-dirs as if they're within the mount
namespace of the target process.
We still need to do external-debug-dirs, but that will be slightly
difference as it does not need further translation.
This just ensures that we can parse the contents of the superblock options
that we get for "overlay" mounts via toolbox/podman. These still need to
be handled from SysprofMountNamespace when translating though.
Additionally, this stuff seems very brittle for parsing, unless it is
getting escaped somewhere I'm missing currently.
That way we are clamped to what the mapping actually provides. This only
seems to get messed up with glibc, but not clear why and it's barely off
so perhaps it has some special mapping tricks it does.
I still notice some non-reproducible runs, but that appears to be related
to duplicate address mapping entries for [stack] which we need to clear
up by removing the duplicate (short) entry.
This represents the SysprofCaptureCtrset and allows fetching the raw values
for a given counter. These are raw because they may not be endian swapped
and that is the responsibility of the consumer.
SysprofDocument will use these eventually to store the values for a given
counter and the time of the value shift.
And add a SysprofDocumentCounter that will represent each counter. Still
to do is implementing the ctrdef type and a way to transform those into
the individual counters.
This symbolizes using the SysprofCaptureJitmap frames within the capture
document. Currently it only implements the fast path which can avoid a
binary search on the jitmap data.
