Date: Wed, 7 Jul 1999 09:44:20 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@netplex.com.au> Cc: Martin Cracauer <cracauer@cons.org>, Martin Cracauer <cracauer@freebsd.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 genassym.c machdep.c src/sys/i386/include frame.h src/sys/kern kern_sig.c src/sys/sys signal.h signalvar.h Message-ID: <Pine.BSF.4.10.9907070940260.558-100000@salmon.nlsystems.com> In-Reply-To: <19990707083327.BC23F78@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Jul 1999, Peter Wemm wrote: > Martin Cracauer wrote: > > In <Pine.BSF.4.10.9907070820410.328-100000@salmon.nlsystems.com>, Doug Rabson > wrote: > > > > I find it hard to beleive that OSF/1 uses (int, int struct sigcontext *) > > > > for non-SA_SIGINFO signal handlers. So where does it get the struct > > > > sigcontext from? > > > > > > Always the third argument as far as I know. > > > > Ah. If OSF/1 only needs the pointer to the struct sigcontext, and if > > all arguments are 64 bits wide (respectivly passed in places where 32 > > bit values don't cause a tighter placement of the next argument), we > > Registers don't have alignment, no 'struct sigframe' remember.. :-) > > > could in fact use both of > > (int, int, struct sigcontext *) [Old FreeBSD style] > > and > > (int, siginfo_t *, struct sigcontext *) [POSIX SA_SIGINFO] > > without breaking binary compatiblity to OSF/1. > > This is what I implimented. We do the first without SA_SIGINFO and the > second with it turned on. > > > Thus, it would be doable to drop the old FreeBSD style, except when > > OSF/1 somewhere uses the integer second argument (which I doubt, this > > is FreeBSD-specific, IMHO). > > Generic BSD. Incidently, from the single unix spec: > > === > The ISO POSIX-1 standard defines the third argument of a signal handling > function when SA_SIGINFO is set as a void * instead of a ucontext_t *, but > without requiring type checking. New applications should explicitly cast > the third argument of the signal handling function to ucontext_t *. > > The BSD optional four argument signal handling function is not supported by > this specification. The BSD declaration would be: > > void handler(int sig, int code, struct sigcontext *scp, char *addr); > > where sig is the signal number, code is additional information on certain > signals, scp is a pointer to the sigcontext structure, and addr is > additional address information. Much the same information is available in > the objects pointed to by the second argument of the signal handler > specified when SA_SIGINFO is set. > === > > It specifically acknowledges the fourth arg as the address, as it is on the > i386 under old style handlers. Hmm... I wonder if this is available (for > completeness) on the Alpha too? > > ucontext_t is basically a superset of a 'sigcontext' and is used for > getcontext(), setcontext(), makecontext() and swapcontext() in user mode. > Inside the ucontext_t is machine-specific struct, which could well be a > sigcontext for us. Our sigreturn() is approximately equivalent to > setcontext(), minus the extra link fields etc. Things like the fault address and reason are in the sc_traparg_a0,a1,a2 fields of the sigcontext. These fields get the three arguments passed to trap() by the palcode and are defined by the Architecture Reference in the section 5.4 of the OSF Palcode part. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.10.9907070940260.558-100000>