Date: Wed, 07 Jul 1999 16:33:27 +0800 From: Peter Wemm <peter@netplex.com.au> To: Martin Cracauer <cracauer@cons.org> Cc: Doug Rabson <dfr@nlsystems.com>, 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: <19990707083327.BC23F78@overcee.netplex.com.au> In-Reply-To: Your message of "Wed, 07 Jul 1999 09:28:47 %2B0200." <19990707092846.A4743@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990707083327.BC23F78>