Re: RFC: A new MIPS64 ABI

[David Daney <ddaney@caviumnetworks.com>]

On 05/06/2011 01:29 AM, Alexandre Oliva wrote:
> 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.
>

Correct.

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

No, this is pretty much what Ralf and I came up with on IRC.

We tag u32 objects (in a similar manner to how non-executable stack is 
done).  The linker will propagate the u32 tag as it links things together.

u32 shared libraries are compatible with legacy n32 binaries as long as 
the OS doesn't map any memory where the address has bit 31 set.

When the OS loads an n32 executable it would check the u32 tag (both of 
the executable and ld.so) and adjust its memory allocation strategy.

The OS will continue to map the VDSO at the 2GB point.  This will cause 
the maximum size of any object to be compatible with the 32-bit n32 
ptrdiff_t.

I think once the OS puts a process into u32 mode, there is no going 
back.  We would just have ld.so refuse to load any shared objects that 
were not compatible with the current mode.

We would continue to place libraries in /lib32, /usr/lib32, 
/usr/local/lib32, etc.


David Daney