Use C++ Termination Handler for catching Xtensa exceptions and do error handling

[aborisovich]

Architectural support for Exceptions by Xtensa HiFi4 Core (MTL)

Currently despite using mostly C code, and C++ code present in modules now is compiled with exceptions turned off,
Xtensa toolchain may throw exceptions that occur during some operations like null pointer dereference, divide-by-zero, window overflow exception and floating point exceptions (Invalid Operation, Divide by Zero, Overflow, Underflow).
HiFi4 core specification IEEE-754-1985 (HiFi4 DSP User's Guide) defines 5 types of exceptions:

• Invalid Operation
• Division by Zero
• Overflow
• Underflow
• Inexact

In debugger we observe that there is some Xtensa provided exception handler that causes firmware to spin in while(true) loop.
According to Xtensa Microprocessor Programmers Guide, DSPs with LX architecture (MTL) with core ace10_LX7HiFi4 are based on Xtensa Exception Architecture 2 (XEA2).
XEA2 provides three vectors for exceptions and level-one interrupts:

• UserExceptionVector
• KernelExceptionVector
• DoubleExceptionVector

Exceptions share the stacks and state save and restore mechanisms with interrupts except that they don’t switch to the interrupt stack if it is not already in use. EXCCAUSE register contain information about the exception while EPC register shows next instruction to be executed after returning from from exception handling.

According to Xtensa System Software - 2.2.5 Exception Management programmer can register their own exception handler using
function

int32_t xtos_set_exception_handler(uint32_t excnum, xtos_handler
handler, xtos_handler * pprev);

that works similarly to C++ Termination Handler but provides access to some registers with debug information, may use C function as callback and works in the interrupt context.

Existing solution

SOF RTOS legacy platforms seem to have this exception handler implemented using _xtos_set_exception_handler function in
src\arch\xtensa\xtos\exc-sethandler.c.
It is worth to note that Xtensa System Software document states that function _xtos_set_exception_handler is obsolete and will be removed in future releases.

Zephyr platforms - @lyakh indicated there is a Zephyr file zephyr\arch\xtensa\core\fatal.c that contains a function char *z_xtensa_exccause(unsigned int cause_code) that is called from arch\xtensa\core\xtensa-asm2.c and it looks like some heavy assembly and python job is done in zephyr\scripts\coredump\gdbstubs\arch\xtensa.py and arch\xtensa\core\xtensa-asm2-util.S .
Probably there is some code generation and assembly is needed to hook into the hack stack frames and exception handling mechanism itself.

Idea

Implement custom user exception handler in SOF side when using native Xtensa toolchain (not Zephyr SDK) replacing "not very clean" assembly + python + whatever else solution in Zephyr. Data received from exception can be integrated with new logging mechanism or error codes we consider.

References (from ace10_LX7HiFi4 Xtensa core docs):
Xtensa Microprocessor Programmers Guide
Xtensa Instruction Set Architecture (ISA) Reference Manual
Xtensa System Software
HiFi4 DSP User's Guide

[lgirdwood]

@aborisovich this will need to be in Zephyr as it's mostly architectural layer. These vectors are part of the sof codebase today, but I think they are not used in Zephyr config (as Zephyr versions would be used). Agree, they are NOT helpful at all today.

IIUC the assembler "spin" exception vectors should jump to Zephyr arch/platform C code that would dump the information i.e. Zephyr arch code (that can generate the stack, thread dump etc) that can also then call the platform/application context dump as described by @mmaka1 (which then adds application context and copies to SRAM window)

[andyross]

So... I'm not touching the C++ angle here. :)

That said: indeed there is a standard/portable Zephyr fatal error handler already. It's a little spare in Xtensa; lots of things that could be reported to the user aren't. But the basics are there, and user code can register a sys_fatal_error_handler() hook that can do whatever architecture/platform-specific magic it wants, including things like terminating the offending thread and/or unwinding its stack to run a handler (though that gets into deep voodoo territory).

But if we do this, let's try not to put C++ exception details down into the kernel? An API that allows a trap to return into async thread mode code (like a Unix signal, basically) is all that's needed. But it would be a lot of work.