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.
For RISC-V and Cortex-M-not-3, triples are known and have worked in some
configuration, but do not work at the moment and stay disabled until the
reference platforms (native, M3) have been established well.
This introduces KCONFIG_BOARD_CONFIG and KCONFIG_CPU_CONFIG variable for
boards and CPUs (including common directories) to add default
configuration files to be merged. The current approach, as it uses
Makefile.features, would include boards first, not allowing them to
override CPU configurations.
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.
On `native` the functions stdio_read() / stdio_write() were not
used.
Those functions are intended for alternative stdio implementations.
As a result, no alternative stdio could be used on `native`.
To fix this, call the functions in `_native_read()` / `_native_write()`
when dealing with stdio fds.
Currently implementations of the MTD api are selecting the module,
this makes it easy for default backends to be selected. But the
correct modeling is simply selecting the MTD api and then selecting
a backend. BOARDs providing one of the backends can expose this and
then that backend can be selected by default.
There is also currently nothing preventing from using the MTD api
with no backend since a mock backend can easily be provided as is
done in all mtd tests.
