Subject: Re: N32
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 01/03/2002 15:58:32
At Thu, 3 Jan 2002 22:31:05 +0000 (UTC), email@example.com wrote:
> So modifying sys/arch/mips/include/types.h so that mips_reg_t is always
> long long seems reasonnable to me, since this will work with no overhead
> for o32, n32 and n64. I think about removing alls the #if on
> _MIPS_BSD_API and just do typedef long long mips_reg_t
> Is this reasonable?
Well, aside from the following results of changing that type, yes it's
(1) it's completely unnecessary and wasteful on 32-bit MIPS systems.
I.e., the systems that typically have the least performance to
(2) it breaks binary compatibility in a number of places. The ones
that jump out are:
* everything that uses sigcontext or related data types
* core dump
There are probably more.
In addition, I'd guess that it'll hose DDB, but i'm not completely
sure about that.
Oh, did i mention that the 'yes' above was a little sarcastic? 8-)
So, there are two choices that I see, really:
(1) make NetBSD userland bits see all of the above in their current
sizes. You can do this, and pass the 64-bit values around in the
kernel. It won't be trivial, but it's probably doable.
You wouldn't be able to get meaningful coredumps or run debuggers
even on the assembly of the n32 binaries though.
(2) The Right Thing: go the whole mips / mips64 route, with the
'mips64' kernels only being runnable on MIPS III, IV, V, and 64
processors, obviously. Allow N32 (and 64-bit) binaries to be run
only on the latter.