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.
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.
This isn't what it will look like in final form, just get the minimum
there for us to use it with the bundled decoder (copied from libsysprof
with adaptations).
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.
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.
