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.

The second problem is that the trampoline is not writable by user 
processes so GDB cannot set software breakpoints there.  I've tried to 
deal with that in the single-step hook by having it effectively step 
over the trampoline by setting the breakpoint on its return address, but 
for operations like "finish" or "advance" that use the stack unwinder to 
get the location to set the breakpoint, it seems like there is nothing 
to do but kfail the tests.

OK to commit?

-Sandra