[PATCH][MIPS] Add linker emulation for N64 ABI with forced 32-bit symbols

Maxim Kuvyrkov maxim@codesourcery.com
Thu Nov 15 22:18:00 GMT 2012

On 16/11/2012, at 10:56 AM, David Daney wrote:

> On 11/15/2012 01:47 PM, Maxim Kuvyrkov wrote:
>> This patch fixes linking of applications compiled with -mabi=64 -msym32.
>> The -msym32 GCC options forces MIPS backend to emit 32-bit symbols even when compiling for 64-bit ABI, which is most useful for building applications with PLTs to call shared library functions (PLTs are currently supported only for 32-bit symbols for MIPS).  Certain applications get a significant performance edge from using PLTs, and such applications should be compiled with "-mabi=64 -mplt -msym32".
>> Compiling with the above options works just fine until linker tries to put the .text section above 32-bit address space at TEXT_START_ADDR="0x120000000".  This patch sets TEXT_START_ADDR to 0x10000000 (which is same as for N32 ABI) when compiling with -msym32 GCC option.
>> I will post the corresponding GCC patch that tells the linker to use new emulations shortly.
>> Tested by building complete MIPS64 toolchain (including glibc) with -msym32.
> I don't understand how this is possible.  The operating system will load shared libraries outside of the lower 2BG of virtual address space.  How coulde glibc possibly work when built like this and it is loaded at a 'high' address (as is normally done in Linux systems)?

I'm fuzzy on the details (this was implemented >2 years ago), below is what I remember.  There also was a prerequisite patch for this (http://sourceware.org/ml/binutils/2011-11/msg00097.html) with an explanation of sorts.

The parts that stuck in my brain is that the library being loaded above 32-bit address space is not a problem.  As long as .plt of the executable is in 32-bit address space, things work (can't remember exactly why, though).

This all will become irrelevant should Richard S. push for N64 ABI to be switched to use N32-style TEXT_START_ADDR.

Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

More information about the Binutils mailing list