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 uses an augmented red-black tree to create an interval tree with
non-interval lookups. That amounts to storing address ranges within the
red-black tree, but looking up by single address.
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.
