From owner-freebsd-arch Sun Jan 6 15:29:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 61D0837B400 for ; Sun, 6 Jan 2002 15:29:38 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020106232938.SEDR288.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sun, 6 Jan 2002 23:29:38 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g06NTbs46838 for ; Sun, 6 Jan 2002 15:29:37 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9F87D38CC; Sun, 6 Jan 2002 15:29:37 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Archie Cobbs Cc: Alfred Perlstein , Dan Eischen , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <200201062000.g06K0La35178@arch20m.dellroad.org> Date: Sun, 06 Jan 2002 15:29:37 -0800 From: Peter Wemm Message-Id: <20020106232937.9F87D38CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Archie Cobbs wrote: > Alfred Perlstein writes: > > > Is there a reason that getcontext and setcontext need to be > > > system calls? > > > > Atomicity? > > That can't be why.. otherwise this would imply that just because > something is written in assembly instead of C that it could have > atomicity problems. Well, consider that setjmp()/longjmp() have embedded system calls (ie: sigprocmask).. SVR4 (ie: including Solaris) use setcontext etc to return from signals and it needs to restore the signal masks etc. The posted patches also have sigprocmask(2) syscalls in the get/setcontext implementations. Since it is going to make a syscall anyway, why not push it all to a syscall? It would also allow you to return to a VM86 context. 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. 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.. eg, the kernel can do this in getcontext: /* save machine state */ getgregs(p, ucp->uc_mcontext.gregs); /* If we are using the floating point unit, save state */ if (p->p_pcb.pcb_fpu.fpu_flags & FPU_EN) getfpregs(p, &ucp->uc_mcontext.fpregs); else ucp->uc_flags &= ~UC_FPU; Secondly, it may be that the process has got a saved fp state, but it may not be loaded into the FPU registers.. It may be stashed in pcb_fpusave still and waiting for the first reference to fault into the kernel so that it can load them into the fpu registers again. If the context save was done in the kernel then it could copy the fpu registers from the pcb if that is their current official location. Solaris seems to have getsetcontext(int cmd, ucontext_t *ucp), where cmd == GETCONTEXT, SETCONTEXT etc. I think they use this as a helper for the library routines. They'd call that instead of sigprocmask() and manually saving the regsters. The libc functions would probably deal with the link stuff. BTW2; the i386 implementation doesn't have the full FPU state.. ie: no SSE or SSE2 context. It should be using fxsave/fxrstor if present, which is an additional reason to do this in the kernel.. BTW3; the ia64 has got some "interesting" handling required here. Having libc_r use these new functions means that libc_r will be a step closer to working on ia64. I suspect that fpu state handling on the ia64 will require a syscall to do it efficiently. > BTW, I think this adding these is a great idea.. e.g., the pth port > can take advantage of these as well. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message