tum-ei-eda / etiss

Extendable Translating Instruction Set Simulator
https://tum-ei-eda.github.io/etiss/
Other
29 stars 36 forks source link

SimpleMemSystem: introduce simple_mem_system.error_on_invalid_access cfg #147

Closed PhilippvK closed 4 months ago

PhilippvK commented 4 months ago

Allows to (optionally) crash the simulation in case a RX (read-only, execute) segment was written or ETISS tries to execute code in RW (read/write) segments.

The default behavior (just throwing a warning) should not change.

wysiwyng commented 4 months ago
  1. To actually terminate the simulator using the logging facility etiss::log you need to use loglevel etiss::FATALERROR.

  2. 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.

PhilippvK commented 4 months ago

@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.