Hi Finn,
Am 03.05.2023 um 16:11 schrieb Finn Thain:
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.
Right - we don't have anything at present that would use signal handlers
in this way (that we'd know of) but it's a legitimate use.
(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
Thanks - I have those but hadn't looked at that section yet.
Linux requires a FPU (real or emulated) and FPU conditional instructions
might hit this bug (even though any code compiled by our binutils should
avoid it). Better fix this now that we're poking around in this area of
the kernel.
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...
No, seeing the coprocessor conditional branch case we want this patch
even if we decide to handle data faults differently.
That is, unless Andreas can come up with a reason why calculated branch
target adresses cannot be used with these coprocessor branch instructions?
Cheers,
Michael
