Hi,
On 23.5.2023 4.11, Michael Schmitz wrote:
On 22/05/23 23:41, Geert Uytterhoeven wrote:
...
I plan to send this upstream later this week, so any additional
testing would be appreciated.
I've given this some lengthy stress testing, and haven't seen it fail once.
In contrast, various attempts of mine to improve on the concept (by only
moving the signal frame away from the USP in case it's likely to clash)
sometimes came up against a kernel bus error in setup_frame() when
copying the signo to the signal frame. I must be making some incorrect
assumptions still ...
Limiting the signal frame shift to bus fault exceptions that happen
mid-instruction is not too much of an overhead even in low memory
settings, and using 256 bytes (the largest possible operand size, i.e.
the largest adjustment to USP that might occur on completion of the
interrupted instruction) did not seem to cause any issues with stack
growth either.
I can give this some more testing in ARAnyM (extending the stack shift
to format 7 frames) but I'd say it's got as much testing on 030 hardware
as we can do.
Aranym emulates only 040 (without CPU cache).
For 030 system emulation, you can use either WinUAE (Amiga) or Hatari
(Atari).
Those emulate (using WinUAE CPU core) all 68000 - 68060 models,
including MMU *and* CPU cache.
Note: MMU+cache combination has some issues with Linux on Hatari though,
so you need to disable cache & prefetch emulation to be able to run
Linux user-space with Hatari [1]. Apparently these issues do not happen
on WinUAE, so that seems better 030 Linux test platform for now.
- Eero
[1] https://hatari.tuxfamily.org/doc/m68k-linux.txt
