On Wed, 3 May 2023, Michael Schmitz wrote:
So the case that you are concerned about here is where the instruction in execution is e.g. a moveml using USP as one of the data addresses (making USP unreliable) and the instruction faulting is one of the next ones being decoded. [...]
Right. The instruction in execution may be an incomplete stack operation like MOVEM. If the signal handler fixes up the address error, that stack operation might be resumed after sys_sigreturn(), like the bus error case. The kernel allows the exception frame to fixed up by the user program.
(You mentioned cpBcc or cpDBcc instructions in another mail - where did you find that? It's not mentioned in my copy of the 030 UM...)
It's in the 3rd edition (1990), section 10.5.2.8. https://www.nxp.com/files-static/32bit/doc/ref_manual/MC68030UM-P1.pdf https://www.nxp.com/files-static/32bit/doc/ref_manual/MC68030UM-P2.pdf
I'm not trying to say this all isn't necessary for address errors. I'm just trying to understand why it is.
I haven't yet tried to write code to demonstrate the theoretical address error issue but I can attempt that if need be. However, such code would be moot if this patch is going to be required anyway, just to fix the bus error case...
