Looking at the code of _metal_trap, I think it is not interrupt-safe. That is because the code is setting up mepc and mcause first, before disabling interrupts by writing to mstatus. If an interrupt occurs after setting up mepc and mcause but before writing to mcause, then the values in mepc and mcause will be overwritten and I think they will not be restored by the interrupt handling code.
By the way: I don't understand the calculation of the value for mepc. I guess addi t0, ra, -1 is used to rewind mepc to the instruction in front of the one where execution should continue. But how can applying -1 lead to the correct value, when all RISC-V instructions have to start at an even address and compressed and uncompressed instructions can be mixed?
RoccoMatano
commented
4 months ago
Looking at the code of
_metal_trap, I think it is not interrupt-safe. That is because the code is setting upmepcandmcausefirst, before disabling interrupts by writing tomstatus. If an interrupt occurs after setting upmepcandmcausebut before writing tomcause, then the values inmepcandmcausewill be overwritten and I think they will not be restored by the interrupt handling code.By the way: I don't understand the calculation of the value for
mepc. I guessaddi t0, ra, -1is used to rewindmepcto the instruction in front of the one where execution should continue. But how can applying-1lead to the correct value, when all RISC-V instructions have to start at an even address and compressed and uncompressed instructions can be mixed?