Sandra Loosemore <sandra@codesourcery.com> writes:
Earlier versions of the nios2 kernel used to allocate code for signal
handler trampolines on the stack, but when the port was accepted
upstream it was changed to instead put the trampoline at a fixed
address in low memory (0x1044).
Moving the code off the stack changed the layout of the stack frame,
so the first part of this fix involves updating the offset to the
register save area. This is not an exported interface from the
kernel; I noticed e.g. the existing aarch64 gdb support includes a
huge block of comments explaining the kernel's signal handler stack
frame layout but ultimately also relies on using magic numbers to
access the register save area. I used a somewhat smaller block of
comments for nios2 but I think now it is clear where the magic numbers
come from and what kernel code this corresponds to.
We can make this magic number less magic by documenting how it is
calculated. We did something similar in
tic6x-linux-tdep.c:tic6x_linux_rt_sigreturn_init,
/* The base of struct sigcontext is computed by examining the definition of
struct rt_sigframe in linux kernel source arch/c6x/kernel/signal.c. */
CORE_ADDR base = (sp + TIC6X_SP_RT_SIGFRAME
/* Pointer type *pinfo and *puc in struct rt_sigframe. */
+ 4 + 4
+ TIC6X_SIGINFO_SIZE
+ 4 + 4 /* uc_flags and *uc_link in struct ucontext. */
+ TIC6X_STACK_T_SIZE);