Date: Tue, 6 Jul 1999 23:28:40 +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.9907062322460.304-100000@salmon.nlsystems.com> In-Reply-To: <19990706170113.CDA7B78@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 <19990706155057.C664178@overcee.netplex.com.au>, Peter Wemm wrote:
> > > Martin Cracauer wrote:
> > > > cracauer 1999/07/06 00:13:49 PDT
> > > >
> > > > Modified files:
> > > > sys/i386/i386 genassym.c machdep.c
> > > > sys/i386/include frame.h
> > > > sys/kern kern_sig.c
> > > > sys/sys signal.h signalvar.h
> > > > Log:
> > > > Except those applications that access hidden signal handler arguments
> > > > bejond the documented third one. If you have applications that do,
> > > > please let me know so that we take the opportunity to provide the
> > > > functionality they need in a documented manner.
> > >
> > > The one that springs to mind is cvsup (more specifically, the M3 runtime)
> > > that accesses sf_addr to get the faulting address.
> >
> > The SA_SIGINFO implementation doesn't really move sf_addr (the first
> > three arguments are of the same size) and cvsup still runs on my
> > system. Will have to wait for distfile fetching before I can test a
> > build.
>
> I know it doesn't move it, I just pointed it out since you asked for things
> that used the fourth and beyond args. :-)
>
> > > > Also except application that use 'struct sigframe' directly. You need
> > > > to recompile gdb and doscmd. `make world` is recommended.
> > >
> > > I've been looking at the Alpha code to try and figure out how to do this
> > > there too. The calling conventions have me a little confused but I think
> > > I have a handle on it.
> >
> > I would suggest that FreeBSD/alpha doesn't start using two conventions
> > from start. You have few old applications to break.
>
> Only source compatability. Is there anything left in /usr/src that uses
> the old-style args still? It looks like you've been through and zapped
> the couple of places that did.
We need to preserve binary compatibility with OSF/1 programs. The layout
of struct sigcontext is defined by OSF/1 and is not going to change
without a bloody good reason.
>
> > Just treat every signal handler as it requires SA_SIGINFO, since you
> > need additional arguments anyway. If there are some
> > performance-critical computations to do for SA_SIGINFO arguments
> > later, you may choose to skip them out for signal that don't require
> > them. But the point is to push identical structures onto the stack for
> > both cases.
> >
> > Use a struct like this for the arguments (like i386, but simplified
> > since only one case must be supported):
> >
> > struct sigframe {
> > int sf_signum; /* Required by Posix, in register */
> > siginfo_t *sf_siginfo; /* Required by Posix, in register */
> > void *sf_third; /* Required by Posix, in register */
> > struct siginfo_t sf_store; /* A place where the second
> > * argument points to, on stack */
> > };
> >
> > The first three arguments are pushed into registers by convetion, on
> > i386 and on alpha.
>
> Umm, no.. The i386 does not pass the first 3 args in registers for normal
> calling conventions. Executing the signal trampoline is a very special
> case and is not a normal "call".. the kernel tweaks the context so that the
> user process suddenly finds itself running the trampoline. It then makes a
> normal call (in user mode) with the stack pointer set to the sigframe (with
> the various sf_signum etc values) which simulates a normal args-on-stack
> call.
>
> The Alpha doesn't do this the same. It's sigcontext is defined by the
> PALcode (it's as good as hardware defined in this case).
You have this confused with the minimal PCB (struct alpha_pcb) which is
defined by PALcode. The sigcontext is defined by OSF/1.
> Instead of
> the handler being in the 5th arg from (%esp) like on the i386, the kernel
> itself sets up the registers for the user call and puts the address in
> the t12 register. The signal trampoline has *NO* stack frame to deal with
> at all. The sigcontext pointer is in the a2 register (the third argument)
> and is saved across the signal handler call (from t12) in order to get back
> to the old context for sigreturn().
>
> There's the key difference. The i386 has args-on-stack calling conventions.
> The i386 signal delivery sets up a stack frame so the trampoline can call
> the handler with the prebuild arguments. The Alpha has 1st 3 regs calling
First six :-)
> conventions and the kernel sets the registers for the user handler directly,
> and the trampoline has to avoid touching them. We are pretty much stuck with
> the third arg being *scp otherwise the trampoline has to muck about with
> saving and restoring more registers.
Again, don't change the calling convention for signal delivery without
knowing exactly what is going on. The current ABI works well and can be
used unchanged for OSF/1 and probably Linux emulation.
--
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.9907062322460.304-100000>