We still have some work to do here so it doesn't mess up the summary
augmentation, but this is a start on re-generating the callgraphs for a
specific symbol.
This has an indirect object (SysprofCallgraphSymbol) so that we can provide
plumbing to get the callgraph as well as the augmented data from the
indirection object.
This allows for callgraphs to show overview in the functions list which
contains the same augmentation that the descendants view does.
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.
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.
This adds a specific frame type for the Jitmap frames in the capture files.
You can iterate them without having to bswap as well, which is why this
does not use the SysprofCaptureJitmapIter (which does require bswap'd
frames).
We need to separate a number of concerns here, such as debug-dirs within
the process namespace vs global debug-dirs (external symbols on a developer
workstation vs IoT/Laptop/VM/alternate-device).
That means we need to be able to resolve paths via the mount namespace of
the process as it was seen in the capture file.
Additionally, we need to follow .gnu_debuglink section headers so that we
can associate the version with symbols with the ELF that is loaded from
the processes SysprofAddressLayout.
This instead moves to a public API on the document to symbolize now
that we've gotten much of the necessary bits private in loading the
document. This commit ensures that we only do loading via the loader
now (and removes the incorrect use from the tests so they too go
through the loader).
We check for NoSymbolizer in document symbols so that we can skip any
decoding. That keeps various use cases fast where you don't want to
waste time on symbolizing if you don't need to look at symbols.
There is plenty more we can do to batch decode symbols with some more
API changes, but that will come after we have kernel/userland decoding
integrated from this library.
We may still want to get all symbols into a single symbol cache, but
given that we have address ranges associated with them, that may not
be very useful beyond the hashtable to pid-specific cache we have now.
If symbols were shared between processes, that'd make more sense, but
we aren't doing that (albeit strings are shared between symbol
instances to reduce that overhead).
We will want to start embedding this content in the capture file (but
after gzipping it as it's otherwise quite large). This will get things in
place so that we can parse that .gz file into the address ranges and
decode symbols found within the capture file.
and thereby make a bunch of the exposed API on SysprofDocument private.
Instead we'll push some of that to the loader but for now the tests can
keep doing what their doing using the private API.
The goal here is to not expose a SysprofDocument pointer until the document
has been loaded and symbolized via the loader API. Then we can lookup
symbols directly from the document w/o intermediary objects.
And expose it via sysprof_document_process_list_mounts() so that when
inspecting processes we can see what binaries were mapped as well as what
the filesystem looked like to locate those mapped paths.
This internal type is used to collect things about a process like the
memory maps, address layout, and symbol cache. This can persist once
parsed at startup, then applied to objects created on demand such as the
SysprofDocumentProcess or used by symbolizers internally rather than
complicated function arguments.
This relies on begin/end range for the symbols to create something akin to
an interval tree, albeit with GSequence. If performance needs to be
addressed, can probably augment SysprofSymbol for an interval rbtree.
We have "chunks" within the capture file, this object will represent the
collection of those chunks which is easier for applications to deal with
if they want to view the contents.
This is meant to be a simple index helper where we already have a bitset
created for a low-cardinality index. We can reuse the read-only bitset
and filter on the document itself.
This index will keep a reference on the document so it's lifetime persists.
The goal here is that we can try to reproduce to some degree the mount
namespace as the PID saw it, but also convert that to paths where we can
find the files on the host system.
The goal here is to have a memory map for each of our processes so that we
can translate a memory address into an offset within a file.
We will then use an upcoming SysprofMountNamespace as a view into a process
file system layout to convert the mapped filename into something we can
access from the current process (be it on the host, or via flatpak, etc).
This exposes the types and hierarchy but won't expose the API details that
we need internally. The idea here is that we can keep that private so we
can adjust how it is used should we need to since the public interface
would be the SysprofDocumentSymbols, not the SysprofSymbolizer which does
decoding directly via address/context state.
The goal here is to get an object to represent a symbol so that we can
more easily extend things in the future. We'll still use those pointers
as unique in the stackstash in the future.
This is not yet functional, but gets the scaffolding in place that we'll
use to filter out processes and turn them into something more useful such
as their execution lifetime.
Currently, this would need to be implemented by SysprofDocumentSample and
SysprofDocumentAllocation. But we could potentially start allowing many
types to attach a trace if we modifier the capture format to allow it.
Generally this is all the processes at startup, but can also be a process
that is executed while the capture is running. Useful to pair with an
Exit frame for pid/tid duration.
