On Mon, 13 Jan 2025, Maciej W. Rozycki wrote:
> > When requesting csd_stack to be aligned using
> > __attribute__((__aligned__(x))) it seems as if the compiler does not
> > leave enough room above the csd_stack struct. i.e since the exact
> > location of csd_stack depends on the actual value of $sp it is not
> > known at compile time. Seems like gcc does not take this into account.
> > The code works fine if I remove the alignment attribute for csd_stack.
> > Also as previously mentioned, declaring csd_stack as "struct
> > ____cacheline_aligned_in_smp" makes it work, but judging from the
> > disassembly code, this statement has no effect on the alignment of
> > csd_stack, i.e csd_stack is not aligned to anything its simply just
> > placed on the stack, indirectly making it just 16-byte aligned instead
> > of the requested 32-byte alignment.
> >
> > It seems to me that, when used to align variables that reside on the
> > stack, __attribute__((__aligned__(x))) does not work correctly with
> > gcc/alpha/linux.
>
> I smell psABI breakage somewhere causing stack misalignment upframe. It
> has happened before here and there. It could genuinely be a GCC bug, but
> I suspect not. I'd rather suspect handcoded assembly or other kind of a
> manual stack pointer assignment or adjustment made somewhere.
Having actually dug speculatively I can see that the psABI was changed in
GCC 3.5 with commit e5e10fb4a350 ("re PR target/14539 (128-bit long double
improperly aligned)") back in Mar 2004, when the stack pointer alignment
was increased from 8 bytes to 16 bytes, and arch/alpha/kernel/entry.S has
various suspicious stack pointer adjustments, starting with SP_OFF which
is not a whole multiple of 16.
If this psABI change was inevitable (I guess it was), then the kernel
side should have been adjusted accordingly. At first glance it seems that
arch/alpha/kernel/ptrace.c may have to be updated as well. Signal frame
handling code might be worth checking too.
Some bugs are good at hiding very well...
Maciej
