Skip to content
Permalink
Browse files

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 <andrew.j.ross@intel.com>
  • Loading branch information...
andyross authored and andrewboie committed May 31, 2019
1 parent ed5185b commit 92ce7670481ac1fdc9ffa4daee5a0ac205b38789
Showing with 1 addition and 1 deletion.
  1. +1 −1 include/kernel.h
@@ -4522,7 +4522,7 @@ extern void z_sys_power_save_idle_exit(s32_t ticks);
#define z_except_reason(reason) do { \
printk("@ %s:%d:\n", __FILE__, __LINE__); \
z_NanoFatalErrorHandler(reason, &_default_esf); \
CODE_UNREACHABLE; \
k_thread_abort(k_current_get()); \
} while (false)

#endif /* _ARCH__EXCEPT */

0 comments on commit 92ce767

Please sign in to comment.
You can’t perform that action at this time.