Date: Fri, 25 Jan 2002 13:40:06 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Eischen <eischen@vigrid.com> Cc: k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, deischen@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <3C51D0B6.F6E04EBC@mindspring.com> References: <20020125082827.88543.qmail@web14005.mail.yahoo.com> <3C515DC8.536C556@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
VMS was POSIX compliant, and this is how it implemented
signals in the context of its own facilities.
It seems to me that signals are rare enough that doing
the OS-based delivery always, and then doing delivery to
user soce based on conditional user code would be a real
possible approach to this.
Basically, there would be a trampoline to user space, and
then all of the signal related system calls, save the
_xxx registration for the user space glue code, and the
kill(2) (only when invoked on another process!) could be
in user space.
Then the get/set context would be capable of being in user
space, always, with the exception of programs that use the
FPU.
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.
If *any* object file during a link process had this flag
set in it, then a .init could cause replacement of soft
pointers used to implement FPU context save code, as
opposed to non-save code. Since the FPU code could be in
a .so file that is later dlopen(3)'ed, then there would
need to be additional work so that ld.so (really, the
wrong place for dlopen's implementation, anyway), could
set the flag while there were outstanding context saves
already in progress.
Thus there would be:
o A flag on the object, to indicate the presence of
FPU code from the code generator
o A flag/code predicate that indicated this to the
executable, via a procedural interface of some
kind, so that function pointers could be overriden
at load time
o A flag in the saved contexts generated by the
{set|get}context function in user space to indicate
a saved context without FPU state, so that a switch
from not saving FPU state to saving FPU state could
be handled on a setcontext() of a context created
via a getcontext() prior to FPU code being present
could work subsequent to its presence.
In other words, to answer the original question, the answer
is "Yes, with appropriate effort".
-- Terry
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?3C51D0B6.F6E04EBC>