On Sat, 25 Jan 2025, Maciej W. Rozycki wrote: > > Interesting. Perhaps these frames are aligned by PAL-code as well, > > the reference manual wasn't clear about that. > > I think it just boils down to the amount of exception nesting. Ah, actually most of these faults were entered from the user mode and the kernel stack starts at a page boundary, so once the stack frame has been allocated by PALcode and SAVE_ALL combined the stack pointer ends up misaligned. For faults entered from the kernel mode the opposite might be the case. So unless we want to play (and we don't) with FP and the saving and restoration of SP, we just want to keep SP aligned at all times. > > I knew about entUna, I thought it's safe as it only deals with 64-bit data > > and not going to be changed in future, but missed entMM... > > > > I agree, better fix both. > > Well, we may get away with it in many cases, which is obviously why > this bug has survived so long, but in principle it is not safe to enter > C code with the stack misaligned, so yes, we need to fix all the code > paths, also because a nested exception will cause hell to break loose. > > Here just bumping up the frame size and adjusting offsets in assembly > code accordingly so as to account for the empty longword at the bottom > of the frame should do, just as I did across my change. ... or, depending on how you look at it, top of the frame and FAOD in any case the longword closest to the stack pointer will be the empty one. Maciej
