Please sign in to comment.
kernel/fatal: Clean up z_except_reason() fallback implementation
Architectures that lack implementations of synchronous traps (via Z_ARCH_EXCEPT()) end up using a z_except_reason() implementation that doesn't actually trap at all. It just invokes z_NanoFatalErrorHandler() in the current thread context. That has two problems: First, it was just blindly assuming that the error handling invoked would abort the current thread, swap away, and never return. But that can be application code in z_SysFatalErrorHandler that we can't control. Second, it was too broad with this assumption and stuff a CODE_UNREACHABLE hint in for the compiler. But in fact z_except_reason() may be invoked in interrupt context (for example the stackprot check) where it may NOT swap away and WILL return synchronously from the call. This doesn't seem to have caused a miscompilation in production code, but it made a total voodoo hash out of my debugging around this macro for an hour or so until I figured out why my logging was being optimized out. Do the abort unconditionally instead of relying on the app, and remove the incorrect compiler hint. Signed-off-by: Andy Ross <email@example.com>
- Loading branch information...