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: [PATCH][MIPS] Add linker emulation for N64 ABI with forced 32-bit symbols


On 11/15/2012 02:08 PM, Richard Sandiford wrote:
Maxim Kuvyrkov <maxim@codesourcery.com> writes:
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.

OK to apply?

Huh. I'm very much against the original change to the n64 TEXT_START_ADDR. See this previous discussion on the topic:

http://sourceware.org/ml/binutils/2008-06/msg00285.html

The justification for changing TEXT_START_ADDR from a 32-bit value to a
larger value was that it would show users if their code was non-portable,
because anything that assumed 32-bit addresses would now fault.  But that
seems to me like the tools lecturing to the user.  As I said in that thread,
I think users who want to smoke out such portability problems (by making
sure that the lower 4GB aren't mapped) should be the ones who need to do
something special.

I think we should simply revert to a 32-bit TEXT_START_ADDR for all
n64 emulations.  This time I'm even in a position to approve it :-)


How about if we move it really low instead of just back to 0x10000000?


At 0x10000000 we are wasting 1/8 of the available -msym32 address space.

David Daney


That has the advantage that no GCC patches are needed.  Users who
want this functionality can just upgrade their binutils.

Richard




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