Date: Wed, 7 Jul 1999 08:44:44 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Martin Cracauer <cracauer@cons.org> Cc: Peter Wemm <peter@netplex.com.au>, 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.9907070841190.328-100000@salmon.nlsystems.com> In-Reply-To: <19990707092846.A4743@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Jul 1999, 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 > 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. > > 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). That makes sense. The second argument (code) is mostly derived from NetBSD but its not really needed since more information is available in the sigcontext. I'm not sure exactly what OSF/1 expects in the second argument. -- 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.9907070841190.328-100000>