kubatyszko wrote:Would moving you to dual 600Mhz, 4.5G RAM Octane2 help ?
Only for the extra CPU muscle.
NCommander wrote:I could go hunting through binutils and see if it uses MAP_FIXED + MAP_AUTOGROW, and change it, but I also doubt that will help ...
You're using GNU ld? It is recommended to configure GCC to use GNU as (it's required for certain features), but use IRIX ld.
An N32 process (such as the linker) can at the best allocate ~ 1.7GB. If shared libraries are mapped unfavorably, this number can be much lower.
Dave Anderson (who worked (works?) in the compiler group) posted a couple of messages in this thread to make the best of the N32 address space.
If that doesn't do the trick, MIPSpro 7.4.1 introduced a prototype 64-bit linker:
Code: Select all
3.2.1 New 64-bit built linker Under certain
circumstances the default linker (because it is
built in the N32 ABI) could run out of virtual
address space and exit with an error: "I/O
Error: Out of Space". To address only those
types of error, MIPSpro 7.4.1m provides an
experimental linker built as a 64-bit binary,
ld64x, which can be invoked as:
%cc -64 -Zl,x t.c
This linker cannot be used in conjunction with
-IPA and is only provided as a workaround when
encountering the above error.
Bug fixes were made all the way to the very last (7.4.4) release; I don't know how stable it really is. I'm not sure how to mod GCC to use it. There's no such thing as ldx32 so this 64-bit ld binary can only be used to produce 64-bit binaries.
If you really want to enter a new world of pain, you could rebuild GNU binutils as N64 binaries to create a 64-bit toolchain capable of building 32-bit binaries. I'm pretty sure you'd be the first. No wait, if I have time later today I'll give it a shot. See what this does for the regression results
The workaround (stripping debug info before linking) is probably a better option