Hi !
When MMU is enabled, and a undefined abort exception is triggered, are we sure that the address stored in the `lr` / `elr_elx` registers is actually mapped by the MMU, or should I check that before trying to access the address ?
Best,
V.
ELR_ELx contains the return address to begin execution from, once the control returns from the exception. If the address inside ELR_ELx is not mapped when the exception returns, a prefetch abort can be expected to be immediately raised.
Did you instead mean FAR_ELx?
Also, by undefined abort, did you mean one of these three: undefined instruction, data abort, prefetch abort?
I meant an undefined instruction (typically in armv7a which would lead to the Undefined Mode). In this mode, we don't have *FAR address, but we have LR. I guess my question could be rephrased:
on armv7a, when entering Undefined Mode, can I assume that the "fault" address which triggered this exception is actually mapped in the MMU and can be read ? If it wasn't the case, I would have gotten a prefetch abort instead, but I can't find a clear reference to this in the ARM ARM.
I think that there are two places where the question about the mapping of such an instruction (the execution of which resulted in an undefined instruction exception) can be raised.
(1) The place when the CPU itself detects that the instruction is undefined. For CPU to know that, it must have had access to the instruction bytes. Thus, those bytes were available for reading, and made their way into the pipeline as expected under typical circumstances.
(2) The place when the handler attempts to read the instruction bytes, in order to emulate the instruction, or enable relevant co-proc hardware, etc. Here, it is not guaranteed that the instruction bytes are available for reading, because it is possible for the mapping to become invalid (for e.g. another CPU invalidated the mapping before the handler could read). This creates a case where a data abort can occur while running the undefined instruction handler. The kernel must be able to handle such cases (alternatively, the kernel must provide a guarantee that such a situation can never arise, in at least some cases if not all, and handle the rest.)
Thank you for this insight. As I am only running on a single core CPU at the moment, I can deal with (2) later :).