Date: Sun, 06 Jan 2002 15:29:37 -0800 From: Peter Wemm <peter@wemm.org> To: Archie Cobbs <archie@dellroad.org> Cc: Alfred Perlstein <bright@mu.org>, Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020106232937.9F87D38CC@overcee.netplex.com.au> In-Reply-To: <200201062000.g06K0La35178@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020106232937.9F87D38CC>