Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacement for the Boot ROM _xtos_set_exception_handler #7820

Merged
merged 2 commits into from
Jan 12, 2021

Conversation

mhightower83
Copy link
Contributor

@mhightower83 mhightower83 commented Jan 11, 2021

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)

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.
Copy link
Collaborator

@earlephilhower earlephilhower left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch on something that looks like would cause a very infrequent but very random problem!

@d-a-v d-a-v merged commit 0203dea into esp8266:master Jan 12, 2021
@mhightower83 mhightower83 deleted the pr-add-xtos_set_exception_handler branch January 13, 2021 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants