Re: RFC: A new MIPS64 ABI

[Alexandre Oliva <aoliva@redhat.com>]

On Feb 15, 2011, David Daney <ddaney@caviumnetworks.com> wrote:

> On 02/15/2011 09:56 AM, Alexandre Oliva wrote:
>> On Feb 14, 2011, David Daney<ddaney@caviumnetworks.com>  wrote:

>> So, sorry if this is a dumb question, but wouldn't it be much easier to
>> keep on using sign-extended addresses, and just make sure the kernel
>> never allocates a virtual memory range that crosses a sign-bit change,

> No, it is not possible.  The MIPS (and MIPS64) hardware architecture
> does not allow userspace access to addresses with the high bit (two
> bits for mips64) set.

Interesting.  I guess this makes it far easier to transition to the u32
ABI: n32 addresses all have the 32-bit MSB bit clear, so n32 binaries
can be used within u32 environments, as long as the environment refrains
from using addresses that have the MSB bit set.

So we could switch lib32 to u32, have a machine-specific bit set for u32
binaries, and if the kernel starts an executable or interpreter that has
that bit clear, it will refrain from allocating any n32-invalid address
for that process.  Furthermore, libc, upon loading a library, should be
able to notify the kernel when an n32 library is to be loaded, to which
the kernel would respond either with failure (if that process already
uses u32-valid but n32-invalid addresses) or success (switching to n32
mode if not in it already).

Am I missing any other issues?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer