We want to have an object hierarchy, but we don't want to expose our class
or other internal details to the public API/ABI. This uses the old form of
class definition so we can maintain that.
An alternative would be to do what GDK does for internal types, should we
find that easier to maintain going forward.
Also handle swapping the data when non-native endian so that we can leave
our GMappedFile unperturbed (and therefore not have to keep those bytes as
dirty pages in process).
This will provide better namespacing for the objects inflated from the
document for various frame types. By creating real objects with real
properties we give ourselves quite a bit of flexibility in the data
filtering language coming forth.
The goal here is to break up libsysprof into a library for recording
profiles (using libsysprof-capture) and a library for analyzing profiles
(both used by the sysprof UI).
This adds a GListModel that we can use to load capture files. The goal here
is to map the entire capture into memory so we can avoid reading lots of
buffers. That also allows for the model items to live as long as the model
is alive (or underlying file map, really).
The next goal is to stack features on top of this such as implementing the
callgraph as a filter of the model, or generic filters between the
callgraph model and the actual data source model.
sysprof_visualizer_group_insert() would insert widgets intended for
position 0 at position 1 instead. This caused a bug in the marks section
where the "Timings" row, which is supposed to be at the top, would
instead be at position 1. Because the menu buttons are in the top row,
disabling a row through the menu could cause the menu buttons to
disappear.
With this change, sysprof can be consumed as a subproject without
making any changes to the build files of a project. All you need to do
is provide a wrap file with a `[provide]` section:
https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
This is also necessary because otherwise projects need to hard-code
the subproject name, which might be `sysprof` when using `wrap-git` or
`sysprof-3.46.0` when using `wrap-file` (to build from a release
tarball). This can cause conflicts between different subprojects that
consume sysprof differently.
Other projects like glib, cairo, pango, etc already do this.
This code uses the hashtable directly to avoid the overhead of calling
the path which creates ProcessInfo entries. So we need to also handle
the chance the lookaside is NULL.
We don't need to dynamically link against libsysprof for sysprof-cli as
we can do the same thing that sysprof-agent does. In fact, we can probably
even make sysprof-cli wrap sysprof-agent in the future (or be the same
binary that looks at it's argv[0]).
If we have tooling that can toggle -finstrument-functions, Builder for
example, then we'd be able to use an LD_PRELOAD to inject the various
function callbacks to record samples.
I dont think we want to use the sample frame type for this though. We
really want something focused on tracing instead and visualize it a bit
differently than the stack trace visualizer.
