Yes, clearly sigtramp in runtime/sys_linux_arm64.s must save all callee-saved registers.

Same for sys_openbsd_arm64.s and sys_netbsd_arm64.s.

Thanks for pointing this out.

CC @4a6f656c

Change https://golang.org/cl/177045 mentions this issue: runtime: save/restore callee-saved registers in arm64's sigtramp

I doubt there is really need to save/restore the registers in sigtramp. We shouldn't allow the C code to call Go functions directly without going through CGO. It is true that A Go signal handler may be called when running C code. But it is not called from C code directly. It is actually called from kernel. Kernel will preserve the context anyway.

I think the question should be: Why we save/restore those registers on darwin system? Is it necessary?

@ianlancetaylor - I don't see why this would be necessary. When a signal is delivered the kernel preserves all of the register state in the trap frame, restoring all of the (possibly modified) register state on return from the signal handler. In the case of OpenBSD/arm64, see sendsig() and sys_sigreturn() in:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/arm64/arm64/sig_machdep.c?rev=1.6

This is fairly standard behaviour - NetBSD is effectively the same via cpu_getmcontext() and the setcontext system call:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/aarch64/aarch64/sig_machdep.c?rev=1.1.28.2

I would expect Linux to do the same.

@4a6f656c This is not a theoretical problem. Signal handlers are used in many different ways by different programs. See #18328.

@ianlancetaylor - fair enough, one could argue that the signal forwarding code should be preserving and restoring context (as the kernel would). I guess saving/restoring is the safe solution, although at a cost for the normal/non-forwarding case.