From owner-cvs-all Wed Jul 7 1:33:36 1999 Delivered-To: cvs-all@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 2D79B150A4; Wed, 7 Jul 1999 01:33:29 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id BC23F78; Wed, 7 Jul 1999 16:33:27 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Martin Cracauer Cc: Doug Rabson , Martin Cracauer , 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 In-reply-to: Your message of "Wed, 07 Jul 1999 09:28:47 +0200." <19990707092846.A4743@cons.org> Date: Wed, 07 Jul 1999 16:33:27 +0800 From: Peter Wemm Message-Id: <19990707083327.BC23F78@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Martin Cracauer wrote: > In , 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. > Martin Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message