Replacement for the Boot ROM _xtos_set_exception_handler by mhightower83 · Pull Request #7820 · esp8266/Arduino (original) (raw)

Adaptation of _xtos_set_exception_handler for Arduino ESP8266 core

This replacement for the Boot ROM _xtos_set_exception_handler is used to install our replacement _xtos_c_wrapper_handler. This change protects the value of excvaddr from corruption.

Details

The issue, the Boot ROM "C" wrapper for exception handlers, _xtos_c_wrapper_handler, turns interrupts back on just before calling the registered "C" function. This leaves excvaddr exposed to possible overwrite before it is read. For example, if an interrupt is taken during the exception handler processing and the ISR handler generates a new exception, the original value of excvaddr is lost. To address this issue we have been using a replacement _xtos_c_wrapper_handler in file exc-c-wrapper-handler.S for the non-32-bit access exception handler. This PR expands access to that replacement by replacing the ROM's _xtos_set_exception_handler .

An overview, of an exception at entry: New interrupts are blocked by EXCM being set. Once cleared, interrupts above the current INTLEVEL and exceptions (w/o creating a DoubleException) can occur.

Using our replacement for _xtos_c_wrapper_handler, INTLEVEL is raised to 15 with EXCM cleared.

The original Boot ROM _xtos_c_wrapper_handler at entry would set INTLEVEL to 3 with EXCM cleared, save registers, then do a rsil 0 (interrupts fully enabled!) just before calling the registered "C" Exception handler. Our replacement keeps INTLEVEL at 15. This is needed to support the Arduino model of interrupts disabled while an ISR runs.

And we also need it for umm_malloc to work safely with an IRAM heap from an ISR call. While malloc() will supply (exception free) DRAM for all allocation from an ISR, we need free() to safely operate from an ISR with (exception generating) IRAM memory. Otherwise, we would have to let the IRAM allocation leak or do a panic.

If an exception handler needs interrupts enabled, it would be done after it has consumed the value of excvaddr. Whether such action is safe is left to the exception handler writer to determine. However, with our current architecture, I am not convinced it can be done safely.

@earlephilhower I think you may need this in #6994 (comment)