The idea here is that we stop having instruments do their own policy
checking and instead do the policy checking as a set from the recording
as part of prepare/etc.
The goal here is to have a fairly small exposed API surface for profiling
similar to libsysprof-analyze where implementation details are hidden.
SysprofProfiler - Where you setup your recording
SysprofInstrument - What you add to a profiler to extract data
SysprofRecording - Represents an active recording w/ instruments
We have a lot of twisted options, and could really use some cleanup to
make that all more manageable. I don't know anywhere we care about not
checking for a C++ compiler, so just always check for that so we can use
the demangler.
I want to move a bunch of this "contrib" style sources into their own
area so we can statically link them but keep them separate from main
sysprof code.
We need to do what binfile was doing and make the address relative to the
text_offset. We also need to ignore the text offset of the debuglink files
and pass it the text_offset of the original ELF.
This fixes a bunch of symbolization in the callgraph.
This just serves as a prototyping ground so that we can have a callgraph
view widget in the future based on these principles. It also shows some
areas that still need work, such as sorting within the tree and fixing the
text offset calculation for ELF symbols.
If our entire stack was in kernel address context, inject the
"- - Kernel - -" symbol at the top of the stack trace so that accounting
gets properly assigned to the kernel. This is typical with kernel processes
such as kworker.
We may need to know the final address context so we can inject symbols as
necessary into the top of the callgraph. We know it when generating the
symbols, so just yield it to the caller too.
This creates a SysprofCallgraph object which is a GListModel of
SysprofCallgraphFrame. The SysprofCallgraphFrame is also a GListModel of
SysprofCallgraphFrame so that we can map this all into a GtkListView in
the future for tree-like visibility.
The augmentation allows for the same callgraph code to be used for multiple
scenarios such as CPU sampling as well as memory allocation tracking.
If your augmentation size is <=sizeof(void*) then you do not occur an extra
allocation and you can use the inline augmentation space.
The test-callgraph clearly shows that we still need to do the shuffling
of -- Kernel -- and -- User -- like the old callgraph code did. But that
will come soon enough.
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.
