> 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?

The port which uses MIPS_64BIT_CLEAN should use another magic number
for the executables. (to distinguish the executables and the shared
objects are compatible with existing MIPSLE32 or not)

seems to be questionable for me.
--
soda