Re: [PATCH] PPC64 Add ucontext.h and *context functions

[Paul Mackerras <paulus at samba dot org>]

Steven Munroe writes:

> However if the [u]context is the result of a signal (sigalarm), ctr may
> contain valid data (a loop counter).  Paul Mackerras suggested using
> rt_sigreturn to restore the context in the case the context is generated
> by a signal.  This requires a wink and nod between glibc and the kernel
> since normally only the signal trampoline (built by the kernel) uses the
> rt-sigreturn syscall.  To use rt_sigreturn we must convert a ucontext
> address parameter (r3) into a "sigframe" stack entry (r1).
> 
> To minimize glibc/kernel dependencies, the 2.4.21 PPC64 kernel changes
> the signal trampoline to first pop the dummy frame (via addi) before the
> rt-sigreturn syscall. This means that when rt_sigreturn gets control R1
> points directly at the sigframe. The layout of the sigframe was also
> adjusted so the ucontext struct is now at offset 0.  So the ucontext
> address (R3) is also the "sigframe" address.  Copy R3 to R1 and syscall
> rt_sigreturn.

As I recall it, I suggested adding a setcontext system call.  The idea
of using the rt_sigreturn system call for setcontext in the case where
the ucontext_t comes from a signal handler invocation was in order to
provide compatibility with older kernels.  I therefore think that
relying on a change to the way the kernel delivers signals is a bad
idea.

I suggest instead that we should define a setcontext system call, for
both ppc32 and ppc64.  The glibc setcontext should then try the system
call, and if it gets an ENOSYS error, fall back to either restoring
the registers in userspace (if the context came from get/make/
swapcontext) or using the rt_sigreturn hack (if the context came from
a signal handler invocation).  If we are using rt_sigreturn, we should
expect the behaviour of older kernels (i.e. an offset between r1 and
the ucontext pointer).

For ppc32, I want to redefine the mcontext so that it has space for
the floating-point and altivec registers, i.e. the mcontext will not
be a sigcontext.  We can't change the ppc32 sigcontext at this stage,
unfortunately.

Regards,
Paul.