On Tue, 19 Jan 1999, Jonathan Stone wrote:

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

Thanks for taking the time to work on this now.  I realize that NetBSD
is a volunteer effort, and sometimes things slip through the cracks.

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

An n32 userland is something we're definitely interested in, but it's 
probably a lot more work as the toolchain isn't quite up to it yet.

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

This sounds good to me.  To make it more concrete,
we could use the variable which I'd already defined in mips/include/types.h
and have something like:

#if defined(_MIPS_BSD_SIM) && _MIPS_BSD_SIM == _MIPS_SIM_ABIX32
#define _JBLEN 120
#define	_JBOFFSETOF_SC_REGS	16
#define _JBOFFSETOF_SC_FPREGS	292
#define _JBOFFSETOF_SC_MASK	460
#else
#define _JBLEN 84
#define _JBOFFSETOF_SC_REGS 12
#define _JBOFFSETOF_SC_FPREGS 152
#define _JBOFFSETOF_SC_MASK 320
#endif

I'll move the genpubassym.cf code into /usr/src/regress and make
it generate a compile-time error if there's a mismatch.

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

By simply using the right datatype, my experience has been that things
just work.  ptrace operates in terms of the variables and datatypes
defined in reg.h and they're currently set to mips_reg_t.
 gdb is an exception, but only because it's had to deal with so many
bunged up architectures that it's very suspicious of what it gets.

You all should be proud that it's clean enough to just work when the the
right datatype is chosen.

	-castor