Date: Fri, 25 Jan 2002 17:03:35 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <Pine.SUN.3.91.1020125164325.24428A-100000@pcnet1.pcnet.com> In-Reply-To: <3C51D0B6.F6E04EBC@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jan 2002, Terry Lambert wrote: > Dan Eischen wrote: > > k Macy wrote: > > > I apologize in advance if this is a stupid question, > > > but would it be possible to make it a compile time > > > option, or a pthread_set* function to have getcontext > > > and setcontext be user-level functions for programs > > > that don't use floating point? > > > > In non-threaded programs, getcontext, setcontext, and > > swapcontext always save and restore the signal mask, so > > they would result in system call anyways. The rationale > > is that if you have to make a system call to set the mask, > > you might as well make the whole function a system call > > (and get/set the FPU state as well to avoid a subsequent > > trap when trying to do it in userland). See the long > > thread in -arch about this. > > Can't you handle this with a user space glue trampoline, > with signals being delivered to the process *always*, > but delivered to the user's code based on user space > masking/trapping registrations with the signal code? It's not signal delivery that is the problem, it is the process signal mask. Signals are always delivered to the threads library signal handler which then delivers them to the correct thread. But the threads library keeps track of the process signal mask (as well as installed signal handlers, sa_masks, etc) and can't have the application change them with getcontext/setcontext (since the signal mask is part of ucontext_t). > Then the get/set context would be capable of being in user > space, always, with the exception of programs that use the > FPU. Yes, that is the plan. > The FPU usage is problematic, but is also resolvable, as a > tools issue. > > Specifically, if an ELF section were generated whenever > the compiler generated FPU code (let's call this section > "flags", for the sake of argument), then the flag "FPU=1" > could be set there. [ ... ] Interesting. I think we only care about FPU state during signal deliver and preemptions though, and in that case, the kernel can just pass us the "FPU used" flag and/or "FPU format" along with the interrupted context. When the context is resumed, it can look at the flag/format and see whether it needs to restore the FPU state. -- 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.1020125164325.24428A-100000>