Replacement for the Boot ROM _xtos_set_exception_handler #7820
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
to handle installing our replacement `_xtos_c_wrapper_handler`. Simplified install in the non 32-bit exception module to make use of the improved `_xtos_set_exception_handler` Reorganized and improved comments.
earlephilhower
approved these changes
Jan 12, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adaptation of
_xtos_set_exception_handlerfor Arduino ESP8266 coreThis replacement for the Boot ROM
_xtos_set_exception_handleris used to install our replacement_xtos_c_wrapper_handler. This change protects the value ofexcvaddrfrom 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 leavesexcvaddrexposed 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 ofexcvaddris lost. To address this issue we have been using a replacement_xtos_c_wrapper_handlerin fileexc-c-wrapper-handler.Sfor 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_handlerat entry would set INTLEVEL to 3 with EXCM cleared, save registers, then do arsil 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)