Date: Mon, 15 Nov 1999 11:09:38 +0100 From: Marcel Moolenaar <marcel@scc.nl> To: Martin Cracauer <cracauer@cons.org> Cc: Bruce Evans <bde@zeta.org.au>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <382FDBE2.D075594@scc.nl> References: <382E8A1B.B7D9B7F0@scc.nl> <Pine.BSF.4.10.9911142303390.21828-100000@alphplex.bde.org> <19991115095729.A27507@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Martin Cracauer wrote: > > 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. I disagree. Signal handlers don't use context information for (wild guess) 99.9% of the time. Bloating signalling definitions with details of the many different hardware configurations (even within a single architecture) is not the way to go. For every FP emulator with it's own state information, we are forced to have unions and the like. No, it's better to be vague in struct sigcontext and let the program use a cast when it wants to dig in the gory details of the machine state. > 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. SUSv2 defines sa_sigaction as: void (*) (int, siginfo_t*, void*) sa_sigaction; Notice the `void*' where the `ucontext_t*' is supposed to be. SUSv2 simply says that the handler may cast the `void*' to get to the gory details and ucontext_t itself contains an abstract type (mcontext_t) that represents machine specific state. Point: You don't want low-level details embedded in high-level definitions. > 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. In that case, make ucontext_t 512 bytes and scale struct sigcontext accordingly. > We may also need an way to tell an application at runtime how far the > struct is filled. You need exactly 1 bit to tell the application if the FPU state is valid or not, right? -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org 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?382FDBE2.D075594>