On Thu, Sep 30, 2010 at 02:50:17AM +0100, Maciej W. Rozycki wrote: > On Wed, 29 Sep 2010, David Daney wrote: > Not exactly. These GNU C library functions rely on the magic value of > "1" there to recognise contexts they created themselves and which must > therefore be handled by themselves internally (these contexts are not > complete and only preserve the call-saved registers as specified by the > respective MIPS ABIs, and are therefore unsafe to be passed to the > rt_sigreturn(2) syscall). All the other values, including of course "0", > are not treated specially and the context is passed to rt_sigreturn(2) as > usually. This only matters in cases where e.g. setcontext(3) is used to > exit from or return to a signal handler. Nothing has changed in that respect; setup_sigcontext() (and its counterparts) do _not_ use regs->regs[0]. Note err |= __put_user(0, &sc->sc_regs[0]); for (i = 1; i < 32; i++) err |= __put_user(regs->regs[i], &sc->sc_regs[i]); in there. The whole point of ->regs[0] uses (both original and modified) is that $0 is constant 0 and thus the kernel is free to use that member of pt_regs to indicate that syscall restart might be needed. So's libc, for that matter (to distinguish between sigreturn and setcontext ones). When sigframe is created we still discard the value - the fragment above is not modified at all. BTW, with original code regs->regs[0] *can* be 1, if you are leaving syscall with -EINVAL. It won't reach the userland, though. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html