Simulation Loop ReturnCodes aliasing with Architecture Exception Codes

[JoGei]

Observation

From Testing the new Architecture (PR #127) , minor concerns in Exception Handling:

Coroutine-Plugin exceptions, be it Interruptplugin or any others, are handled in the main simulation loop within etiss::CPUCore::execute:

etiss/src/CPUCore.cpp

Lines 712 to 718 in 0d215c8

	if (unlikely(exception != RETURNCODE::NOERROR)) // check exception
	{
	etiss_CPUCore_handleException(cpu_, exception, blptr, translation, arch_.get()); // handle exception
	if (unlikely(exception != RETURNCODE::NOERROR)) // check if exception handling failed
	{
	goto loopexit; // return exception; terminate cpu
	}

First, they are consumed by the ETISS exception handler to filter out ETISS-internal exceptions as defined per etiss::Returncodes.

Then, per default, all non-listed Return-Codes are forwarded to the architectural exception handler.

I see the problem here more with some Return-Codes being interpretable as legal Architecture Exception Causes, e.g., ...

etiss/include_c/etiss/jit/ReturnCode.h

Lines 189 to 191 in 0d215c8

	defineReturnCode(CPUTERMINATED, 0x80000001,
	"Terminates cpu execution. this is the proper way to force an "
	"exit from etiss::CPUCore::execute (e.g. by a debugger).");

... translating to a RISC-V 1 0 User software interrupt (USI p. 34)

The old (RISCV) Architecture seemed to handle etiss::CPUTERMINATED incorrectly-correctly, as it seems the USI just was not implemented correctly? The new one does consume the Code as it should - as a RISC-V interrupt - which makes the etiss::CPUTERMINATED unusable from Plugins.

Fix?

Split the two (Simulation-Loop ReturnCode) and (Architecture Exception Code).
Maybe add a new "Simulation Event Type" that holds both, an Event(=Simloop-Returncode) and optionally an attached Value type. Something like that:

struct SimEvent{
  int32_t event_;
  int32_t value_;
};

SimEvent usip {etiss::ArchException, 0x80000001};

Then force all Plugins to use this struct to pass information. Could possibly pack the two into a 64-bit type?

[wysiwyng]

Exception handling in ETISS always assumes (and to my knowledge always has) that error codes are from ReturnCode.h, and therefore are always ETISS-specific, architecture-independent. The problem described arises from the fact that the new translation of ETISS-specific error codes to RISC-V-specific error codes of #127 does not have a good fallback for unknown ETISS-specific error codes. Currently, the fallback translates all unhandled error codes to an illegal instruction exception (see https://github.com/wysiwyng/etiss/blob/2a29d8e605d0031c960fbb59cf379de54ff614c3/ArchImpl/RV64IMACFD/RV64IMACFDFuncs.c#L236 or https://github.com/tum-ei-eda/etiss_arch_riscv/blob/11ae382dff6537b58cfb5031de556ee8a3a5b809/tum_mod.core_desc#L132). The old exception handling implementation simply returns the unhandled error code to its caller as a fallback (see https://github.com/wysiwyng/etiss/blob/2a29d8e605d0031c960fbb59cf379de54ff614c3/ArchImpl/RISCV/RISCVArchSpecificImp.h#L323).

My proposed fix would be to implement handling of ETISS-specific error codes that will never be thrown by the CPU simulation model itself in etiss_CPUCore_handleException and change the new fallback mechanism to terminate the simulator signaling a spurious error code instead of raising an illegal instruction exception.

[JoGei]

My proposed fix would be to implement handling of ETISS-specific error codes that will never be thrown by the CPU simulation model itself in etiss_CPUCore_handleException and change the new fallback mechanism to terminate the simulator signaling a spurious error code instead of raising an illegal instruction exception.

Agree. But this still begs the question of how we avoid the aliasing Returncode.h exception codes with possible ISA-defined Exception codes that we might want to pass through the simulation loop, e.g., InterruptPlugin.

[wysiwyng]

Normally this should never happen though. If CoroutinePlugins want to raise exceptions, they have to do so with the ETISS-specific codes. The current exception/interrupt implementation assumes that architecture-specific codes are only present within the architecture code itself, and therefore interprets all external error codes as being ETISS-specific.