Date: Mon, 15 Nov 1999 09:57:29 +0100 From: Martin Cracauer <cracauer@cons.org> To: Bruce Evans <bde@zeta.org.au> Cc: Marcel Moolenaar <marcel@scc.nl>, Martin Cracauer <cracauer@cons.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991115095729.A27507@cons.org> In-Reply-To: <Pine.BSF.4.10.9911142303390.21828-100000@alphplex.bde.org>; from Bruce Evans on Sun, Nov 14, 1999 at 11:22:16PM %2B1100 References: <382E8A1B.B7D9B7F0@scc.nl> <Pine.BSF.4.10.9911142303390.21828-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In <Pine.BSF.4.10.9911142303390.21828-100000@alphplex.bde.org>, Bruce Evans wrote: > On Sun, 14 Nov 1999, Marcel Moolenaar wrote: > > > Martin Cracauer wrote: > > > > > Reserve space for FPU state in struct sigcontext. Fix some style bugs > > > > and comments while there. > > > > > > I still don't like this approach of unstructred allocated space, an > > > array of unnamed bytes. > > > > It's what it says it is: it's a space reservation. If someone actually > > implements saving the FPU state, then he/she is free (IMO) to change the > > reservation into whatever he/she things he/she needs or thinks is > > meaningful. > > Martin implemented saving it before you complicated things by changing > the signal handling :-). I didn't like it because it moved the definitions > of i386 FP structs to the wrong place (<machine/signal.h>). It's not > clear that there is a right place. The reasoning is like this: 0) If the state of the FPU is passed to a signal handler, it is preferrable to do so in a struct with proper names, not just an array of bytes. 1) Applications that use signal handlers with extended parameters (SA_SIGINFO or old BSD-style three arguments) are supposed to include <signal.h>, but nothing else. 2) Hence the descriptions of the state of the processor(s) that are passed to the signal handler must be visible from signal.h. It's already the case for the CPU, I just add the FPU. > > The reason for the space reservation is to work towards an unified > > context. mcontext_t also has the space reservation... > > We seem to have missed allocating some necessary space. glibc-2.1.1 has: Changing the contents of struct sigcontext is not nearly as bad as changing its size, so I would suggest that we reserve some more space for things that might seem useful to pass to signal handlers in the future. struct save87 is now 176 bytes, Marcel currently reserves 180. struct sigcontext without FPU state is 100 bytes, so we are at 276 bytes at least. Would it be unreasonable to bump it to 512 bytes to be done with it once and for all? Might have positive effects on cache behaviour as well. We may also need an way to tell an application at runtime how far the struct is filled. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991115095729.A27507>