We need to at least submit this data to the underlying FD from our buffer
when we stop recording so that anyone consuming the FD will have access to
it. (Such as a SysprofDocumentLoader via FD).
This allows setting the net.hadess.PowerProfiles during the execution of
the Sysprof run. This is handy if you want to test in a specific mode (such
as performance) but not leave your system in that state.
This ensures that we don't clobber things by writing them without possible
translation. That is problematic when each controlfd process might have
it's own counter registration or JIT maps as they could collide with the
main writer's own state.
This fixes some situations where the counter data was coming in with
erroneous values.
This is like sample but has an "enter/exit" flag with it. This can be
useful when you want to provide tracing instead of sampling. We use a
different frame type so that we can denote that this isn't traditional
sampling, and the flag can be used to find the next exit for the current
enter for calculating durations.
The entire stack trace is provided to make things easier on tools
which may want to deal with indirect functions that were not instrumented
but can be unwound. That may allow for tooling to give the user some
insight that it's not *just* this function entering, but some functions
before it were entered too.
This also adds a SysprofTracer instrument which will preload a
libsysprof-tracer-6.so into the process providing the
__cyg_profile_func_enter() and __cyg_profile_func_leave() hooks.
This allows instruments to record a diagnostic and have it land as an
object in a GListModel of diagnostics available to the API consumer.
Such items may be used by recording UI to display issues with the recording
to the user.
This is a SysprofInstrument that will eventually contain the contents of
the sysprof-battery-source.c to get battery charge/rate/etc. Note that
this is different from energy usage which will come from RAPL.
This uses G_REGEX_OPTIMIZE as well to get the benefit of the JIT when using
PCRE2 via GLib.
This turns out to take about half (or less) of the time that it takes to
use sscanf() to parse the template/input string. 0.03 vs 0.08 seconds on
my system.
If someone wants to take this further, and just look at the input string
rather than rely on GRegex, that'd be fine by me too.
We will always have either \n or \0 at the end, so we can just sscanf this
without needing to split strings.
The sscanf() is still our top offender though, and so we should probably
look for other ways to parse this string than sscanf().
That is the instrument that really provides things within the kernel
address space, so it should be the instrument which copies the contents
of kallsyms to the capture file (compressed).
We have a fairly large buffer for perf events, so we should be able to
process these much less frequently to help reduce the process performing
the profile from showing up in the profiling results.
