+patofiero,anglin On Fri, May 18, 2012 at 12:56 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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? Sorry - I only knew about the state of the HPUX support...Carlos and Dave (and a few others) understand the syscall interface. I've include them directly and hopefully they can respond soon. cheers, grant > 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
