ci/woodpecker/push/woodpecker Pipeline was successfulDetails
Some architecture-specific implementations of the FETCH_LINKPTR
(e.g. the one for x86) attempt to find the linkptr relative to the
stack pointer. Therefore, they make assumption about the value of
the SP at the point where the FETCH_LINKPTR code is executed. This
means that we don't want the C compiler to mess with our SP.
For this purpose, local variables in this function are currently
declared using the register storage specifier. Additionally, we
need to make sure that a frame pointer is /always/ omitted for
this function. On x86 Alpine, the frame pointer is presently not
omitted with GCC 13 when using -Os, therefore the tests segfault
with -Os on Alpine presently.
Fixes#52
The arm ABI defines that the value in register r0 is used as the return
value of a function. To indicate success for get/set/swapcontext (return
value of 0) the register r0 must contain zero at the end of the function
call. Thus set r0 to zero and store it in the context. This context
is restored later and indicate successful execution, because r0 is 0.
The order registers are stored has changed so that only one additional
instruction (mov r0, #0) needs to be added to fix the return value
bug for get/set/swapcontext.
Signed-off-by: Volker Christian <me@vchrist.at>
_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.
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
Sören Tempel
Ariadne Conill