This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: A new MIPS64 ABI


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]