In map_head_and_body_twice(), the second mmap call fails:
mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xf64a2000
mmap2(0xf64b3000, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0x1000) = -1 EINVAL (Invalid argument)
Due to cache issues, all shared mapping of a page must be equivalently
mapped. This requires page mappings to be at the same virtual address
modulo 4 MB. Due to a kernel limitation, all mappings to a file must
be equivalent.
The test can be fixed by rounding the buffer_size used in the mapped
ring buffer to 4 MB on hppa. This makes the two mmap mappings equivalent.
Bug-Debian: https://bugs.debian.org/1021853
This allows tacking on suplimental data to the capture with a build-id so
that our SysprofDocumentMmap can read it. The format is @build-id\0 after
the trailing \0 of the filename in a SysprofCaptureMap frame.
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.
With this change, sysprof can be consumed as a subproject without
making any changes to the build files of a project. All you need to do
is provide a wrap file with a `[provide]` section:
https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
This is also necessary because otherwise projects need to hard-code
the subproject name, which might be `sysprof` when using `wrap-git` or
`sysprof-3.46.0` when using `wrap-file` (to build from a release
tarball). This can cause conflicts between different subprojects that
consume sysprof differently.
Other projects like glib, cairo, pango, etc already do this.
Really what we want to deal with here is tracking an overlay that we may
need to be able to decode after the fact (in case processes exit or we
need to do post-processing symbol resolution).
For the podman case, that is $some_path mapped to root (/), generally
speaking. For flatpak though, that would have two mappings, one for
/app and another for /usr (possibly more).
While I'm not thrilled to add new frame types for every sort of thing, I
think having this will be relatively useful so we can improve decoding
operations.
This adds SysprofCapturePidRoot which lets us specify a root directory
on the host system for which is the real root (/) of the PID. This can
be useful when reconstructing overlays for containers and you need to
direct access to alternate roots.
The layer gives us some ability to try to deal with overlayfs, albeit at
a very rudimentary level. In most cases I anticipate we just deal with
the main root and ignore overlays until necessary.
All three of these structs are already defined in
`sysprof-capture-types.h`, which is included from these three headers.
Drop the duplicate definition to silence the Clang warning:
```
In file included from /opt/gnome/install/include/sysprof-4/sysprof-capture.h:63:
/opt/gnome/install/include/sysprof-4/sysprof-capture-cursor.h:67:38: warning: redefinition of typedef 'SysprofCaptureCursor' is a C11 feature [-Wtypedef-redefinition]
typedef struct _SysprofCaptureCursor SysprofCaptureCursor;
^
/opt/gnome/install/include/sysprof-4/sysprof-capture-types.h:98:41: note: previous definition is here
typedef struct _SysprofCaptureCursor SysprofCaptureCursor;
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This fix error when gio is a subproject, when there is pc file
assotiated for objects in libraries_private meson automatically promote
them to requires.
Also remove some values that are already the default.
This allows Meson to associate the pkg-config module with the "main"
library that it represents, in an unambiguous way.
Signed-off-by: Simon McVittie <smcv@debian.org>
