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.
This symbolizes using the SysprofCaptureJitmap frames within the capture
document. Currently it only implements the fast path which can avoid a
binary search on the jitmap data.
This adds a specific frame type for the Jitmap frames in the capture files.
You can iterate them without having to bswap as well, which is why this
does not use the SysprofCaptureJitmapIter (which does require bswap'd
frames).
If we get an address that doesn't fall within a symbol, we still want to
generate a valid string/address range for it here so that we can get
nick annotations correct. If we hit the fallback path, we won't get that.
There are still lots of kinks to iron out of this, but it gets some of the
basic plumbing in place for symbolizing. Particularly, we're not at all
yet addressing the overlays in the capture which will be needed to do some
handling of Flatpak/Podman processes.
Basic build-id/file-inode checks are done, but we just return NULL in those
cases (unlike previously in Sysprof where we would say "Inode Mismatch". In
those cases the fallback path is hit now which will just give a file path
plus instruction-pointer offset. We can show more details though in the
future now that we have more objects to represent things.
We want to know the inode of the FD that was mmaped so that we can check
the requested inode when processing the address map from a particular
process.
We still want to load it into the cache as it could get used by other
symbols/mmap regions, but don't return the ELF if it won't match an inode
or build-id check. Rely on other fallbacks to create fallback symbols
for those use cases.
We do need to at least translate the path to what we would want to see
from the host system before inserting/resolving, so that we don't risk
collisions in the cache.
In podman (at least with toolbox) it appears to give access to home via
/var/run/host/home/ so we don't need to translate home paths at all.
However, Flatpak does not give you home access via that path so we just
have to hope that we have access to $HOME from whatever application
mount namespace we're running from. That means to do symbolizing in a
Flatpak app you'd likely need --filesystem=host to be useful.
This is the description of the field in fstab(5) so we want to match that
so it's a bit more clear what we're keying off of when translating to a
mount device we can access on the host.
This acts somewhat like g_file_get_relative_path() in that if it is not a
subdirectory of the parent, NULL is returned. Otherwise the relative path
is returned. We can just dive into the substring instead of copying which
is a bonus point.
