Subject: Re: 64-bit-clean userland on mips [was Re: brokenness]
To: None <castor@geocast.net, jonathan@DSG.Stanford.EDU>
From: Noriyuki Soda <soda@sra.co.jp>
List: port-mips
Date: 01/20/1999 11:41:27
> I'll move the genpubassym.cf code into /usr/src/regress and make
> it generate a compile-time error if there's a mismatch.

No. It isn't right thing.
Please think about the 64bit kernel which can execute both old 32bit
mips binary and new 64bit mips binary.
This could be implemented.

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

Mmmm, this sounds not right, too.
Both
	gdb which target is 32bit mips binary can treat 32bit mips binary
and
	gdb which target is 64bit mips binary can treat 64bit mips binary
can run on the same kernel simultaneously.
All crafts which make this possible are already exist in the NetBSD
kernel.
(for example, NetBSD/i386 can execute both
    gdb which target is NetBSD/i386 binary can treat NetBSD/i386 binary
 and
    gdb which target is FreeBSDBSD/i386 binary can treat FreeBSD/i386 binary
)
--
soda