Hi all,

First off, my apologies for this.  I'd drafted a reply to Castor about
the issues with changing _JBLEN (and the register type used for
context-switch structure) immediately before I left for Xmas.  Looks
like I managed not to send that message.  Not following that up
means this mess is largely my fault.

Anyway, I've talked over the issue with Castor.  I'm convinced that
there's worthwhile gain, to some NetBSD users, in supporting both

	a) 64-bit instructions in specific kernel code,
	b) a 64-bit clean userland environment, so that application
	   code can also use 64-bit instructions.

NB: We're _not_ trying to create a new, SGI "n32"-style,
NetBSD-supported mips "port" (precompiled userland, etc).

The idea is to let vendors or other users of NetBSD who want the
ability to do an partial "n32"-style environment (eg., using 64-bit
instructions for a hand-tuned bcopy()) to do so, using the NetBSD
tree, without having to maintain excessive patches of their own.

(Should NetBSD later decide to do either a true 64-bit port ourselves,
or do an SGI "n32"-style port we could use the same hooks to build
mips userlands from a single source tree, but thats down the road..)
The real question is how to accomplish this.

Longterm, I'd prefer to allocate a large enough jmp_buf to handle
64-bit registers, using the low-order portions on 32-bit mips CPUs;
that way the ABI is (more or less) preserved.  That obviously means
either changing the libc major number, or doing __RENAME() tricks.

So here's what I'd like to do short-term, to resolve Castor's
problem. If anyone has a better idea, I'm all ears!

We add a new global Make / cpp variable (for arguments sake, call it
MIPS_64BIT_CLEAN. I'm avoiding "MIPS_N32" because that implies
function-call changes as well).  Turning on that flag would
configure both the kernel and the userland to enable 64-bit-clean
context-switch and setjmp/longjmp.

If MIPS_64BIT_CLEAN is defined sys/arch/mips/include/setjmp.h would be
changed to declare _JBLEN appropriately for 64-bit save/restores, as
would the userland code which handles jmp_bufs.

(The other alternative is that specific ports (eg., Castor's) can
define MIPS_64BIT_CLEAN in their port-specific setjmp.h.  That would
be more robust, at the cost of an #ifdef in the mips/include/setjmp.h.)

How does that sound? Growing jmp_buf and doing _RENAME() has an impact
on other ports; I'd rather avoid that until if and when we decide to
do a supported 64-bit-clean userland with prebuilt binaries.

Last, are there similar issues with the datatype introduced as "size
of a mips register that gets saved/restored on contextswitch"?
Kernel debuggers need to know about that. Does anything else-- 
especially the ABI between ptrace() code and userland?