Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Feb 2002 12:40:08 -0500 (EST)
From:      Daniel Eischen <eischen@pcnet1.pcnet.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG
Subject:   Re: getsetcontext system call 
Message-ID:  <Pine.GSO.4.10.10202221231110.23808-100000@pcnet1.pcnet.com>
In-Reply-To: <20020211210412.X308-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Back to this...

On Mon, 11 Feb 2002, Bruce Evans wrote:
> On Mon, 11 Feb 2002, Daniel Eischen wrote:
> >   http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs
> >   http://people.freebsd.org/~deischen/ucontext/uc-libc.diffs
> 
> I noticed a few minor problems with it, but haven't completely reviewed it.
> 
> >From your original mail:
> 
> ! I also changed the alpha a bit.  When delivering signals, it
> ! dropped the FPU if it was currently owned.  This wasn't done
> ! on i386, and I didn't see a reason why it would need to be done
> ! for alpha.  For i386, signal deliver now includes the FPU
> ! context.
> 
> Well, signals handlers should get a clean FPU state, and you don't
> want spend much time looking at the current state to see if it is
> clean.  Saving the state into the ucontext and initializing a clean
> state without looking is probably best.  For i386's without fxsr,
> saving the state loads a new, clean state into the FPU whether you
> want it to or not, so it would be best to pass that state to the signal
> handler and not put it in the pcb, even though signal handlers probably
> won't use it (saving it to the pcb would usually be a waste of time,
> since the state will usually be restored from the ucontext and not
> from the pcb).  For i386's with fxsr, saving the state doesn't change
> the state in the FPU, so initializing the clean state in the pcb only
> is probably better (forget the state in the FPU).  For i386's with or
> without fxsr, if the signal handler returns it is difficult to tell
> if the state being "restored" is already in the FPU, since the signal
> handler may have modified the ucontext.  Copying the ucontext to the
> pcb and forgetting the state in the FPU seems best in both cases.
> 
> get_fpcontext() and set_fpcontext() don't have the right semantics for
> signal handling.  They try too hard to keep the state in the FPU if it
> is already there, but in sendsig() you never want it (the old state)
> there.

OK, for signal handling the FPU is dropped and a clean FPU state
will be loaded if the FPU is used again.

> I just noticed a not so minor problem: get_fpcontext() on i386's only
> works for the fxsr case, since it assumes that the state is is still
> in the FPU after fpusave().  fpusave() and npxsave() probably shouldn't
> exist, since they mainly obfuscate the critical differences between
> fnsave() and fxsave().

I fixed this by reloading the state in the fxsr case.

Someone's going to have to take a look at the alpha parts.  How
is a clean state handled there?  And if you save the FPU state,
do you have to reload the state or is it similar to the (x86)
fxsr case where the state doesn't get destroyed and init'd after
a save.

Diffs are updated at:

    http://people.freebsd.org/~deischen/ucontext/uc-sys.diffs

-- 
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.GSO.4.10.10202221231110.23808-100000>