Date: Mon, 7 Jan 2002 16:14:59 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Bruce Evans <bde@zeta.org.au> Cc: Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <Pine.SUN.3.91.1020107160532.22099B-100000@pcnet1.pcnet.com> In-Reply-To: <20020108071957.I2280-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Jan 2002, Bruce Evans wrote: > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > Bruce Evans wrote: > > > > > > On Sun, 6 Jan 2002, Peter Wemm wrote: > > > > > > > The context argument passed in to signal handlers should be able to be used > > > > with setcontext() to return from the signal handler as an alternative to > > > > sigreturn(). Doing it in libc wont work there because you race with > > > > restoring the signal mask before you've finished setting the application > > > > state. > > > > > > The i386 siglongjmp() gets this wrong despite using a syscall (sigprocmask): > > > [... example program deleted] > > BTW, the program shows another bug when compiled with -pthread. It crashes > with a SIGSEGV in _thread_sig_wrapper(), apparently due to stack growing > problems. Reducing the size of buf[] from 4MB to 1MB fixes this. The threads library uses an alternate signal stack; you are probably overrunning it. I've got patches under review to get rid of the alternate signal stack so that signals occur on the stack of the currently executing thread. > > I don't really see how having the *context() or *jmp() routines be > > a syscall helps. You still have to protect the accesses to the > > jmp_buf or ucontext for race conditions regardless of whether these > > functions are syscalls or not. There's a few instructions to be > > executed after leaving the kernel via a system call anyways, right? > > You could always get preempted there and have another signal be > > delivered. > > You are back in the context of the caller of setjmp() by then. But I > think that that context, except for the signal mask, can be duplicated > well enough by careful context switching in userland. The jmp_buf must > be "on" both the new and the old stack if it is on a stack at all, The jmp_bufs are stored in the thread structure which is malloc'd; they are not stored on stacks. > since it must remain valid until setjmp() returns. So we can leave > things in jmp_buf (but we shouldn't modify jmp_buf since we might be > preempted by another signal handler that uses it to do a more final > longjmp (we could avoid preemption by blocking _all_ signals, but that > would require even more syscalls)). > > > > > Also, I noticed that the i386 patch doesn't save FP state (!) which is > > > > one of the primary reasons for get/setcontext(). I'm not sure if this > > > > can be efficiently done since this user-level function will not know if > > > > the current context has touched the FPU yet.. > > > > > > I think doing it in userland basically forces you to do physical FPU > > > accesses using fnsave/frstor (and something different for the SSE case?). > > > > We do this in libc_r right now. When a signal is caught, we use fnsave > > to save the FP regs to the ucontext area > > But this tends to give the trap to load the state from kernel memory so > that userland can save it back to user memory. The trap may be more > efficient than a syscall, but that's partly because syscalls are more > pessimized. A single syscall to save the entire ucontext may be more > efficient. fnsave is only used during signals, so the trap wouldn't occur for normal thread switches due to yielding or blocking conditions. > > (knowing the kernel doesn't > > do it for us -- shouldn't it be saving the FP regs?). We remember > > Yes. Use of FP in signal handlers currently corrupts the FP state of > whatever was interrupted (on i386's). Where in the kernel should they get saved (got any patches ;-))? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1020107160532.22099B-100000>