Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12409 Discussions

Global Pointer problem with linker under Nios tools 11.0sp1

Honored Contributor II

I'm attempting to port a very large C++ project (about 1000 source files) from Nios tools version 9.0 (where it builds successfully) to version 11.0sp1. The project is built using the command line tools. 


Under version 11, the build fails with a linker error: 


/opt/altera/11.0sp1/nios2eds/bin/gnu/H-i686-pc-linux-gnu/bin/../lib/gcc/nios2-elf/4.1.2/../../../../nios2-elf/lib/libstdc++.a(locale.o): In function `std::locale::id::_M_id() const': 

/build/swbuild/SJ/nightly/11.0sp1/208/l32/work/ip/sopc/app/gnu/BUILD/gnu/build-0-gcc.nios2-elf.i686-pc-linux-gnu/nios2-elf/libstdc++-v3/src/../../../../src/gcc-4.1/libstdc++-v3/src/ warning: Unable to reach (null) (at 0x00e77e74) from the global pointer (at 0x00d217f0) because the offset (1402500) is out of the allowed range, -32678 to 32767. 


I think we encountered a similar problem several years ago with an earlier version of the Altera tools, and the application makefile already has the -G0 flag set to turn off the use of the Global Pointer Register. I've also added to flag to our bsp settings, using: 

--set hal.make.bsp_cflags_user_flags -G0 


Something, somewhere still seems to be accessing the Global Pointer Register for this error to occur, but I can't work out how to turn it off. Has anyone else encountered this problem ?
0 Kudos
2 Replies
Honored Contributor II

You might be just falling foul of a change Altera made between the gcc3 and gcc4 versions of the compiler. 

The gcc4 version doesn't put items with external linkage into the 'small data segment' (gcc3 did). So code compiled with gcc3 might be trying to use gp-relative addressing for items gcc4 has placed in a normal data area. 

Another possibility is that the linker isn't correctly mapping all the 'small data' sections together - maybe it gets bss ones wrong?? 

Having looked at the generated code, using gp relative addressing is a big win on code size and speed - mostly by reducing register pressure (no regsiters kept with the addresses of global data in them). 

You can do better though, putting all the static data into a single structure and using a global register variable to point to it generates better code! 

In you case I'd look at the linker map file to find out why a symbol is so far from the global pointer - I can't believe you have that much data that would be put into the 'small data' segment.
Honored Contributor II

I have the same problem!! do anyone have a solution???