Date: Mon, 11 Feb 2002 08:13:09 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Bruce Evans <bde@zeta.org.au> Cc: Peter Wemm <peter@wemm.org>, Dan Eischen <eischen@vigrid.com>, arch@FreeBSD.ORG Subject: Re: getsetcontext system call Message-ID: <Pine.GSO.4.10.10202110756480.4-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
On Mon, 11 Feb 2002, Bruce Evans wrote: > On Mon, 11 Feb 2002, Daniel Eischen wrote: > > > On Wed, 6 Feb 2002, Peter Wemm wrote: > > > Daniel Eischen wrote: > > [ ... ] > > > > > > > > Is it OK to leave struct fpreg unchanged for now? > > > > > > To be quite honest, I think that's the right thing to do for now, until it > > > is clear what the "right" thing to do is. ptrace(2) isn't going to survive > > > KSE unscathed, so perhaps we need an enhanced ptrace interface at some point > > > that doesn't suffer from this kind of interface fragility. > > > > OK, done. Can I consider this reviewed and OK to be committed? Diffs > > with your comments incorporated are at the same place: > > > > 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). But if you already own the FPU, doing anything in the PCB is a waste of time. You're not going to get a trap to reload the state from the PCB, and the next FPU context switch will dump the current FPU state to the PCB (overwriting the clean state). > 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. But again, if you know that the thread owns the FPU, saving it to the PCB doesn't do anything. Unless you want to drop FPU ownership everytime you deliver a signal as alpha does. > 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, so we want a clean FPU state whenever signals get delivered, saving the old FPU state in the ucontext. Do you want to drop FPU ownership and initialize the clean state in the PCB? And how do you get a clean state for with and without fxsr? Does fninit do it for both? If we want to initialize the PCB with a clean state, where do we copy it from? > 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'll have to take a look. -- 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.10202110756480.4-100000>