Closed PhilippvK closed 4 months ago
To actually terminate the simulator using the logging facility etiss::log
you need to use loglevel etiss::FATALERROR
.
I disagree with just crashing the simulator in this case, this is not how hardware works. Depending on the target ISA and memory/bus architecture/controller, an illegal memory access like this would cause a bus error, a hard fault, a memory protection fault etc. An ARMv6M hard fault would technically "crash" the target CPU, but should not terminate the simulator entirely. A fault handler can still be called in this case albeit not being capable of recovering the CPU to a valid execution state. A reset of the CPU (possible with ETISS VP) should be able to bring the processor back up. Illegal accesses need to be handled on a per-architecture basis, with the appropriate traps for said target architecture.
Where this PR does make sense is after an MPU or similar architecture-level checks have already passed, sort of as a contingency if the architecture plugin "lets through" illegal access calls.
@wysiwyng
To actually terminate the simulator using the logging facility etiss::log you need to use loglevel etiss::FATALERROR.
Good point. In MLonMCU I was looking for ERROR
in the simulators STDOUT, hence I did not realize that the return code was still zero.
Illegal accesses need to be handled on a per-architecture basis, with the appropriate traps for said target architecture.
Makes sense to me. Let's close this.
Allows to (optionally) crash the simulation in case a
RX
(read-only, execute) segment was written or ETISS tries to execute code inRW
(read/write) segments.The default behavior (just throwing a warning) should not change.