This changes a bunch of things that allows building with the musl C lib,
provided that `libucontext-dev` and `pkg-config` are installed.
Note that installing libucontext makes absolutely zero sense on C libs
that do natively provide this deprecated System V API, such as glibc.
Hence, it no sane glibc setup is expected to ever have libucontext
installed.
A main pain point was that argv and argc are expected to be passed to
init_fini handlers, but that is actually a glibc extension. This just
parses `/proc/self/cmdline` by hand to populate argv and argc during
startup, unless running on glibc.
Initial version to test 64 bit compatibility.
Instead of a separate board, the inital version for Linux/x86_64 is enabled
by setting the environment variable `NATIVE_64BIT=y` and compiling as usual.
Not currently implemented:
* Architectures other than x86_64 or operating systems other than Linux
* No FreeBSD support
* No Aarch support
* Rust support for x86_64
Building `fuzzing/gcoap` with afl-gcc 11.2 gives
/home/benpicco/dev/RIOT/cpu/native/native_cpu.c: In function ‘thread_stack_init’:
/home/benpicco/dev/RIOT/cpu/native/native_cpu.c:120:11: error: variable ‘stk’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
120 | char *stk = NULL;
| ^~~
/home/benpicco/dev/RIOT/cpu/native/native_cpu.c:118:72: error: argument ‘stack_start’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
118 | char *thread_stack_init(thread_task_func_t task_func, void *arg, void *stack_start, int stacksize)
|
We can re-write the function to not use this temporary variable and the error goes away.
Unaligned accesses on x86(_64) are allowed, but slow. However, some host systems
might not be that forgiving. Aligning the stack to sizeof(uintptr_t) should be
a pretty safe safety measure.
And with this done, all casts of the stack pointer that increase alignment
requirements are now intermediately casted to `uintptr_t` to silence
warnings from -Wcast-align - after all the stacks are now manually aligned.
Error case:
1. thread_yield_higher() stores the thread's ucontext
2. creates an "isr ucontext" for isr_thread_yield, switches to it
Case 1: no signals are pending, continues in isr_thread_yield()
3a. sched_run is called
4a. return to sched_active_thread ucontext
Case 2: signals pending (the crashing scenario), continues in native_irq_handler()
3b. handles signals
4b. if sched_context_switch_request is set, call sched_run
5b. return to sched_active_thread ucontext
4b misses the call to sched_run(), leading to a possible return into a
non-ready thread.
The pointer arithmetic for the calculation of the context storage was off
due to the change of the stack's pointer type from unsigned int to char.
Fix offset calculation by not adjusting for unsigned int width anymore.
Fixes#1708.
Currently involuntary preemption causes the current thread not only to
yield for a higher prioritized thread, but all other threads of its own
priority class, too.
This PR adds the function `thread_yield_higher()`, which will yield the
current thread in favor of higher prioritized functions, but not for
threads of its own priority class.
Boards now need to implement `thread_yield_higher()` instead of
`thread_yield()`, but `COREIF_NG` boards are not affected in any way.
`thread_yield()` retains its old meaning: yield for every thread that
has the same or a higher priority.
This PR does not touch the occurrences of `thread_yield()` in the periph
drivers, because the author of this PR did not look into the logic of
the various driver implementations.
