On 3/19/26 22:27, Peter Maydell wrote:
The 64-bit x86 signal frame and the 32-bit signal frame alignment
requirements are slightly different, I think (and this problem and
this patch are dealing only with 32-bit x86). In the kernel's
arch/x86/kernel/signal.c:get_sigframe() they calculate the frame
address like this:
if (ia32_frame)
/*
* Align the stack pointer according to the i386 ABI,
* i.e. so that on function entry ((sp + 4) & 15) == 0.
*/
sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4;
else
sp = round_down(sp, FRAME_ALIGNMENT) - 8;
So x % 16 == 16 - sizeof(void*) is true for 64-bit, but 32-bit is
slightly different.
No, these produce the same alignment, modulo 4 vs 8, i.e. sizeof(void *).
The x86_64 expression is less efficient in the case SP already contains the required
alignment -- it will waste FRAME_ALIGNMENT bytes of unused stack.
I also note that for the data structure I am fixing, we never do
an xsave/xrestore on it -- it is purely junk unused padding.
The real xsave/xrestore info is elsewhere, in the dynamic part
of the signal frame.
That is an excellent point. The structure you're fixing is never really used.
It's only use at present is to be included in the ia32 sigframe structure, and is only
used for padding. As an unintended side effect, the alignment of X86LegacyXSaveArea is
inherited by sigframe.
Perhaps we should simply have
- struct target_fpstate_32 fpstate_unused;
+ char fpstate_unused[sizeof(struct target_fregs_state) +
+ sizeof(X86LegacyXSaveArea)];
r~
