Subject: Re: trap #3
To: ITOH Yasufumi <yasufu-i@is.aist-nara.ac.jp>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: port-m68k
Date: 02/10/1999 19:36:32
On Thu, 11 Feb 1999 07:07:03 +0900 (JST) 
 yasufu-i@is.aist-nara.ac.jp (ITOH Yasufumi) wrote:

 > I'm going to commit this to allow future reuse of trap #3.
 > Any objections/comments?
 > I think this change must be done (if done) before 1.4 cutoff.
 > 
 > I gave up using d0, which makes it difficult to upgrade from -current,
 > but use a0 instead for syscall #.

Sigh, I should have thought of using a0 when I did the trap #3 goo.  The
reason you can't use d0 is that d0 is where return values from functions
are stored.  So, when the trap #2 compat code stuffed SYS___sigreturn14
in there, it stomped on the return value of longjmp().

"Oops."

Anyhow, a0 is a scratch register, and the ABI doesn't guarantee that it
will be preserved in a longjmp(), etc.  However, during _signal_ delivery,
and genuine _signal return_ (i.e. not longjmp()'s use of sigreturn to
restore the context), __a0 must be preserved__, else programs could break.

Sigh... I really want to solve this whole thing by implementing
getcontext(2)/setcontext(2) like SVR4 has.  Then setjmp/longjmp could
be implemented in terms of those system calls (in C even, with the help
of macros to operate on the machine-dependent portions of the ucontext).

Anyhow, the idea I had was that we'd just burn trap #4 on setcontext(2),
and never have to worry about it again.

christos@netbsd.org has the ucontext stuff working on i386 and SPARC,
and I hope will commit it SOON with an ENOSYS stub for ports which don't
have the machdep stuff implemented yet.

So, really, I'd prefer to wait for that.

Sigh, what a mess.  And all because the blasted m68k has variable-sized
exception frames.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>