Hi Geert,
On 24/05/23 00:05, Geert Uytterhoeven wrote:
Hi Eero,
On Tue, May 23, 2023 at 1:40 PM Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
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).
Hence Michael's comment to extend the stack shift to format-7 frames,
which is what is generated on '040 in case of an access error.
Precisely :-)
And I ought to add that this was Finn's idea, to give us more test coverage.
As far as I can remember, the cache isn't involved in this type of
problem. And I might note that due to instruction restart on 040, any
minor stack corruption we cause by the signal stack will be repaired on
return from exception.
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
