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 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.
Additionally this reduces some GHashTable lookup costs by doing it once
for the process-info per-traceable rather than one per instruction pointer
per traceable.
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).
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.
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.
I want to do this differently than we did in libsysprof, which is going
to require a bit of thinking on how we should represent something like
a SysprofMount within the mount namespace.
Now that we have a lot of this indexed, it's fast enough to do on the
calling thread.
# Conflicts:
# src/libsysprof-analyze/sysprof-document.c
# src/libsysprof-analyze/sysprof-document.h
This also indexes the first position of a file by filename so that we can
skip items in the capture file. Generally, embedded files are a single
frame so that will only be one frame to look at. But even when it is a
few frames, they are generally sequential so this vastly reduces how many
frames we'll need to look at for files.
It can be handy to iterate through the traceables and we already have a
bitset index for that. Use the new bitset index listmodel to provide that
filtered list externally without having to inflate every object in the
underlying listmodel, as GtkFilterListModel would have to do.
Instead of walking the listmodel for every object which might be a file
chunk, and treating it as possibly non-native-endianness, this uses the
new index of file chunks and accesses their frame as an object. That
object will do endianness conversions for us.
The extra overhead of creating the GObject is lessened by avoiding looking
at many of the frames in the model.
Create a roaring bitmap of list model positions that contain file chunks.
We can use this in the future to avoid iterating the whole listmodel for
matching file chunks to just the index positions containing file chunks.
