This simplifies deployment on embedded devices, where polkit is usually
unncessary at runtime, but pulls in quite a few otherwise unncessary
dependencies. Start to improve the situation by allowing to selectively
disable polkit-agent support at compile time, which aids in container
usage scenarios, where one wants to invoke 'sysprof-cli' from within
the container. Bypassing polkit-agent in the container is then desired,
since the host sysprofd will handle asking for permissions to enable
the tracing. It allows for a simpler setup of rootless podman
containers, avoiding UID mismatches, that lead to rejection of the
tracing enablement.
- Add a new 'polkit-agent' meson build feature, that allows to force disabling
polkit-agent support (-Dpolkit-agent=disabled).
- Mark the 'polkit-agent' feature as enabled, by default, to reflect
the current status (sysprof-cli did not build without polkit-agent support).
- libsysprof/sysprof-instrument.c: Build fix when polkit is not available,
remove the unnecessary 'g_autopr(PolkitDetails) details' variable.
- Alter the sysprof-cli dependencies to only attempt to link against
polkit-agent, if necessary. Modify sysprof-cli.c to wrap all code using
polkit-agent in HAVE_POLKIT_AGENT blocks.
This fixes an issue where the symbols are not getting T as they are dropped
when pulling in the static archive.
This compiles twice, but that is fine for now until we come up with something
better in the long run.
If we get a container file that is in a format we don't quite understand,
avoid crashing and just bail. That will likely result in the inability
to symbolize properly, but better than crashing.
Fixes#100
We "know" that the swapper runs between each process inherently so no need
to really include that in the scheduler details. It just clutters up the
event timeline. Without it, we're more likely to see patterns in the
scribbles.
That is fine to do when the futures are finished, but in this case one
might still be in-flight. Also, wait for all futures to complete before
processing them. Use a finally() block so we can check even if there are
errors.
This doesn't add support for the legacy symbol mangling scheme which is
currently the default pending support in tools for the v0 symbol
mangling scheme. The legacy symbol mangling scheme is similar enough to
C++'s symbol mangling scheme that demangling them using the C++
demangler generally produces readable symbols. The v0 scheme is entirely
custom and due to backreferences and encoding all generic arguments not
very readable when mangled, so supporting it is more important than
supporting the legacy scheme.
While fixing things for Flatpak (which have a path deduplicating some
of the path parts) works there, it breaks locating the debuglink in
other places such as GNOME OS.
This tries both forms, using the long form first and then the short
form second, since Flatpak is likely a subset of everything that needs
to be located.
If we have a path like /app/bin/gnome-builder and the debug prefix is
/app/lib/debug then we don't want to end up with /app/lib/debug/app/bin
as the real data directory is /app/lib/debug/bin.
This often works with /usr because /usr/lib/debug/usr can link back to it's
parent. But we should try to do the right thing instead of relying on that
anyway.
We need access to this from the process info but can share the instance.
It sucks to walk the hashtable here, but the alternative is to make these
recursive so that we can check a parent mount namespace.
Until then, take the hit and iterate all the pids to populate them with
the additional device.
Related GNOME/gnome-builder#2090
If a new process is spawned after the recording has started (processes
spawned *by* sysprof are done before recording starts) then try to extract
information about that process and append it to the recording.
The goal here is to get enough process information to actually decode the
process without creating fork()/exec() amplification.
Related GNOME/gnome-builder#2090
This is more of what we want to be doing anyway, we don't care about all
the forks in existence.
Additionally, include the comm[] with the pid so that instruments can take
action based on it.
