Date: Wed, 07 Jul 1999 01:01:13 +0800 From: Peter Wemm <peter@netplex.com.au> To: Martin Cracauer <cracauer@cons.org> Cc: 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: <19990706170113.CDA7B78@overcee.netplex.com.au> In-Reply-To: Your message of "Tue, 06 Jul 1999 18:21:48 %2B0200." <19990706182148.A23965@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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). 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
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.
> typedef struct {
> struct sigcontext si_sc; /* Here's the sigcontext you
> * need. */
> int si_signo; /* Required by Posix */
> int si_code; /* Required by Posix */
> union sigval si_value; /* Required by Posix */
> } siginfo_t;
>
> > The "problem" is that the Alpha doesn't have a sigframe, it passes the
> > args to the called functions by register and a pointer to the sigcontext
> > which was pushed onto the stack.
>
> i386 has to push the first three arguemnts into registers as well.
No, it doesn't. It puts them in sigframe on the stack. It sets the
%eip and %esp registers and the segment registers.
> > I am thinking that the easiest way to get this to work will be to
> > additionally push a siginfo_t onto the stack for siginfo signals and
> > change the code argument to point to it and leave the sigcontext
> > pointer as is.
>
> I think it is easier to move the struct sigcontext into siginfo_t and
> pass a siginto_t everytime. The overhead is minimal, the siginfo_t is
> only a little larger than the struct sigcontext. It's a serious
> simplification.
Hmm... since the MI __siginfo has sigcontext right at the beginning
we could use the siginfo_t * as a struct sigcontext * in the trampoline.
Can we be sure si_sc (sigcontext) will remain the first item in __siginfo?
The next question, what is the third signal handler argument used for in
SA_SIGINFO mode? Can it just be zeroed? Or point it to the sigcontext
explicitly?
> I could give it a shot, but I don't have an alpha machine (I need root
> access and either a serial console or a on-site person to boot a
> know-good kernel on demand).
Careful, you might get held to that. :-)
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?19990706170113.CDA7B78>