On Sat, Jan 25, 2025 at 05:01:42PM +0000, Maciej W. Rozycki wrote:
> Yeah, just as I observed in my other reply, but notice that syscalls and
> exceptions handlers typically actually do *not* receive a 16-byte aligned
> stack now.
Interesting. Perhaps these frames are aligned by PAL-code as well,
the reference manual wasn't clear about that.
> > > On stack alignment in "ALPHA Calling Standard":
> > > D.3.1 Stack Alignment
> > >
> > > "This standard requires that stacks be octaword aligned at the time a
> > > new procedure is invoked. During the body of a procedure, however,
> > > there is no requirement to keep this level of alignment (even though
> > > it may be beneficial). This implies that any asynchronous interrupt
> > > handlers must properly align the stack before any standard calls are
> > > made."
> >
> > I hope we can rely on GCC changing $sp only by multiplies of 16.
>
> Absolutely, the compiler would be completely broken otherwise.
>
> > (Yes, there is still the UAPI issue that Maciej pointed out, but that's
> > another story.)
>
> So we now have two variants to pick from. I wish we could take yours as
> it's certainly neater, but is it safe enough?
>
> I can see arch/alpha/include/uapi/asm/ptrace.h was only incarnated as
> late as in 2012 with commit 96433f6ee490 ("UAPI: (Scripted) Disintegrate
> arch/alpha/include/asm") and according to the change heading made in an
> automated way, with little public discussion, so maybe its existence is
> actually an accident? Unlike some other platforms we don't expose this
> `struct pt_regs' via ptrace(2) for PTRACE_GETREGS/PTRACE_SETREGS, which
> we don't implement.
Yeah, a bit of e-mail desync, sorry :)
At the moment I compile gdb with empty asm/ptrace.h just to be 100% sure.
> NB, here's a corresponding stack alignment report for your change:
>
> start_kernel: SP: fffffc0000dcfe90
> do_entInt: SP: fffffc0000dcfc60
> copy_thread: SP: fffffc0000dcfc90, regs: fffffc0000dcff10, childregs: fffffc0001837f10, childstack: fffffc0001837ed0
> do_page_fault: SP: fffffc0001837bb8
> sys_exit_group: SP: fffffc00028bfef0
> do_entUnaUser: SP: fffffc0001bcfe68
> do_entArith: SP: fffffc0001dfbee0
> do_entIF: SP: fffffc0001fafee0
>
> so there's still work to be done for `entMM' and `entUna' exceptions.
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.
Ivan.
