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.
In anticipation of getting PERF_EVENT_MMAP2 events, assume we tack on the
build-id in hex after the filename like "filename\0@build-id\0" so that we
can use it when decoding frames. That will allow us to avoid doing inode
checks (which breaks when moving files between computers anyway) as well
as potentially supporting debuginfod in the future via build-id.
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.
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.
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.
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.
