On Fri, May 18, 2012 at 11:05:46AM -0700, Grant Grundler wrote: > On Fri, May 18, 2012 at 10:58 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > ... > >?Except for that mess with multiple > > pending signals, the value we have in r28 on syscall entry doesn't > > seem to affect the syscall behaviour... ?Some HPUX compat fun? > > We stopped trying to support HPUX compat support probably 8 or so > years ago. Since HP didn't care, no one else did either. So no need > to consider it now. BTW, what should we put into the trampolines of subsequent sigframes when we are building more that one? I.e. suppose we are in a syscall and see two signals. We build a sigframe for the first one, with r25 = 1, call rt_sigreturn() in it. Return address of original syscall is stored into sigcontext of that frame, our return address set to the entry point of handler1. Now we see the second signal and build another sigframe. That one will have the entry point of the first handler stored in sigframe and we'll set the things up so that return to userland will land us in the entry of handler2. Fine, but... what should we have in r25 for rt_sigreturn() in the second trampoline? We return to userland and find ourselves in the beginning of handler2. It's executed and eventually we return from it. We are at the beginning of the second trampoline now. rt_sigreturn() is called, restores the registers from the second sigcontext and returns to userland. We are at the beginning of handler1. It is executed and returns. We are at the beginning of the first trampoline. rt_sigreturn() _there_ restores the original registers from the first sigcontext and we finally return to the insn right after the original syscall (or to the syscall itself if we took a syscall restart). That final rt_sigreturn() will go through syscall_exit; OK, no problem with that. But should the earlier one (done after return from handler2() and landing us at the entry of handler1) go through syscall_exit or through syscall_exit_rfi? -- 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
