On Wed, 29 Sep 2010, David Daney wrote: > > Put the original syscall number into ->regs[0] when we leave syscall > > with error. Use it in restart logics. Everything else will have > > it 0 since we pass through SAVE_SOME on all the ways in. Note that > > in places like bad_stack and inllegal_syscall we leave it 0 - it's > > not restartable. > > > > IIRC Userspace getcontext/setcontext rely on regs[0] having a value of zero in > the when the signal handlers are invoked. 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. > I haven't fully traced through the code, but I hope that this 'invariant' > holds both before and after this patch. I think Maciej did the work on > getcontext/setcontext, he may know for sure what the requirements are. Thanks for the heads-up, David -- I would have surely missed this e-mail from the flood I get. I think the change is safe as MIPS/Linux only uses syscall numbers from 4000 up (not sure why such a non-round number was chosen; one like 4096 would seem more appropriate to me but there you go), so there should be no clash unless an invalid syscall number has a chance to be stored there. For how exactly the magic value is used please have a look at sysdeps/unix/sysv/linux/mips/*context.S in glibc-ports and search for "magic flag" (yes, I know these pieces of assembly butchered and mixed with CPP mince require some mind-twistedness to parse; sorry about that, but I tried my best and put some comments throughout so that the magic flag is easy to find ;) ). Maciej -- 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