From owner-cvs-all Mon Nov 15 0:58:11 1999 Delivered-To: cvs-all@freebsd.org Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 5D26314F36; Mon, 15 Nov 1999 00:57:58 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id JAA27536; Mon, 15 Nov 1999 09:57:30 +0100 (CET) Date: Mon, 15 Nov 1999 09:57:29 +0100 From: Martin Cracauer To: Bruce Evans Cc: Marcel Moolenaar , Martin Cracauer , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991115095729.A27507@cons.org> References: <382E8A1B.B7D9B7F0@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Bruce Evans on Sun, Nov 14, 1999 at 11:22:16PM +1100 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In , 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 (). 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 , 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 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