_GNU_SOURCE can be defined without defining REG_X macros so it is not a
good indicator. (QEMU for example defines it in the build system.) x86
and x86_64 should have consistant looking defs.h so ifndef guards are
added to each REG_X definition.
This is needed because in libucontext.h we include "libucontext/bits.h".
We therefore need to have bits.h in somepath/libucontext/bits.h. In the
Makefile, somepath/freestanding/bits.h was copied to the right path but
in the meson build system, the include copy happens at the end.
The Makefile on ARMv7l devices (e.g. Raspberry Pi 400 running the
stock Raspbian distro) was failing to deduct the architecture and
empty libraries were being built as a result. Building with Meson
works fine; only building with make generated empty libraries.
Add an override for armv7l -> arm in the Makefile to address this.
this is not idiomatic, and should not be done (and it did not even
work in the first place); meson is capable of building both
libraries via library() and then you can choose on commandline
it defaults to only shared, but we want both out of box, so specify
that
it is necessary to tag these symbols as functions otherwise the
linker gets confused; this previously manifested as the internal
functions (pre-rename) like __getcontext leaking into the symbol
table of things linked against libucontext that used the ucontext
POSIX API through the weak aliases
it also had another bad effect and that is if you tried to use
libucontext's API (post-rename), the linker would warn you during
compile time that the type is unknown, and the resulting program
would crash at runtime
after properly tagging everything, I no longer notice any leakage,
i.e. there don't seem to be any references to the aliased symbols
in the resulting symbol table when using the aliases, and using
the libucontext prefixed symbols directly also works
Ariadne Conill
osy