Date: Mon, 11 Feb 2002 22:00:39 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Peter Wemm <peter@wemm.org>, Dan Eischen <eischen@vigrid.com>, <arch@FreeBSD.ORG> Subject: Re: getsetcontext system call Message-ID: <20020211210412.X308-100000@gamplex.bde.org> In-Reply-To: <Pine.GSO.4.10.10202110028440.25166-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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. 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(). > One last question, I added a new file, kern/kern_context.c, that only > has about 90 or so lines in it (including copyright and includes). I > wasn't sure where it fit in, kern_proc.c or kern_sig.c perhaps(?). > Let me know if it should be moved to one of these files or another > existing file. Otherwise, I'll just leave it in kern_context.c. I can't think of a better place than the new file. Bruce 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?20020211210412.X308-100000>