* Patched longjmp to be context-switch safe
longjmp modifies the windowbase and windowstart
registers, which isn't safe if a context switch
occurs during the modification. After a context
switch, windowstart and windowbase will be
different, leading to a wrongly set windowstart
bit due to longjmp writing it based on the
windowbase before the context switch. This
corrupts the registers at the next window
overflow reaching that wrongly set bit.
The solution is to disable interrupts during
this code. It is only 6 instructions long,
the impact shouldn't be significant.
The fix is implemented as a wrapper which
replaces the original first instructions of
longjmp which are buggy. Then, it jumps back
to execute the rest of the original longjmp
function.
Added a comparably reliable test to the
test apps.
The previous approach was to allocate an array on the stack, and
have the array extend past the stack size. This worked by would
result in SP being moved near the end of the stack. If an interrupt
triggered at that time, interrupt prologue would try to save the
context to the stack, tripping the stack overflow watchpoint.
Replacing this with the approach which doesn't move the SP and simply
writes to decreasing addresses from SP, until stack overflow check
triggers.
Small quality-of-life improvement, make it easier to run specific
test cases, when debugging the tests locally.
Take the optional list of test cases to run from the command line.
InstrFetchProhibited usually occurs because of a jump to an invalid
pointer. In this case, PC in the exception frame is the address of
the jump destination. 'esp_ptr_executable' check in print_backtrace
function recognizes the first frame as invalid, and the backtrace is
interrupted. This prevents the user from finding the location where
the invalid pointer is dereferenced.
Bypass the 'esp_ptr_executable' check if the exception cause is
InstrFetchProhibited. Update the test case to no longer ignore this
issue.
Restores the change of startup refactor changes removed the no stack
check protection flag when compiling the source file that contains
execution of constructors - which contains function to setup stack
guard. Restore that and update the source file, since this is in the 2nd
stage of the startup now.
Closes https://github.com/espressif/esp-idf/issues/5617
FreeRTOS scheduler uses additional stack space, as in some functions
variables are placed onto the stack instead of registers.
This issue resulted in occasional stack overflows in dport task, when
compiling at -O0 optimization level.
- Increase the configMINIMAL_STACK_SIZE to 1kB.
- Enable the watchpoint at the end of stack in CI startup test for
this optimization level.