>  > Also, do you remember why _JBLEN got bumped from 83 to 87?
>  > Did struct sigcontext grow by 16 bytes?
> 
> Um, yes!  The new signal masks!
> 
> ----------------------------
> revision 1.2
> date: 1998/09/16 23:15:08;  author: thorpej;  state: Exp;  lines: +2 -2
> Need 87 longs for a jmp_buf now (we use sigcontext, which grew).
> ----------------------------

I asked this before, but I don't think I've seen an answer.  sigcontext
grew with the version change, but I don't think the current one's 87
longs long.

Should (_JBLEN * sizeof(long)) == sizeof(struct sigcontext) or not?

Let's count:

Taken from <mips/signal.h>
	struct sigcontext {
1		int	sc_onstack;	/* sigstack state to restore */
1		int	__sc_mask13;	/* signal mask to restore (old style) */
1		mips_reg_t sc_pc;	/* pc at time of signal */
32		mips_reg_t sc_regs[32];	/* processor regs 0 to 31 */
2		mips_reg_t mullo, mulhi;/* mullo and mulhi registers... */
1		int	sc_fpused;	/* fp has been used */
33		int	sc_fpregs[33];	/* fp regs 0 to 31 and csr */
1		int	sc_fpc_eir;	/* floating point exception instruction reg */
8		int	sc_xxx[8];	/* XXX reserved */ 
4		sigset_t sc_mask;	/* signal mask to restore (new style) */
	};

echo 1 + 1 + 32 + 2 + 1 + 33 + 1 + 8 + 4 | bc
83

As for the 'n32' question, the toolchain needs some serious work before
that can really start.  These interim measures will let us get going.
It's not clear to me that a userland using the 64-bit clean stuff will be
distributed externally before 'n32' exists, but it's valuable to me to
get this stuff checked in to reduce the version control headaches.

	-castor