Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12612 Discussions

problem with code size"need help"

Altera_Forum
Honored Contributor II
1,713 Views

hello, 

I have a problem with code size.. 

I am running an application to view a 24bit color picture on a 480x272 touch screen, I used a 8 Mbyte SDRAM on DE1 board cycloneII and a scatter gather DMA, the only memory in my system is the SDRAM. 

so the reset vector is at 0x00 and the exception vector is at 0x20(and i tried others like 0x2000) 

the problem is that when I include a small picture size like 100x50 pixels every thing is ok, but when I try to include a larger size like 200x100 or full picture 480x272 this message appears: 

 

mallocr.c:2150: warning: unable to reach (null) (at 0x0023814c) from the global pointer (at 0x0022addc) because the offset (54128) is out of the allowed range, -32678 to 32767. 

 

collect2: ld returned 1 exit status 

make: *** error 1 

 

what is the problem? 

I have a 8 MByte sdram and the size 480x272 only needs 0.5MByte??? 

can you help me please?? 

 

0 Kudos
15 Replies
Altera_Forum
Honored Contributor II
650 Views

The linker must be putting your program sections together in an incorrect order. 

 

The 'small data' section is used for small data items (be default less than 8 bytes) so that they can be accessed using a signed 16bit offset from the 'global pointer' (gp) register instead of having to load the 32bit address for each access. 

 

So it looks as though the linker has put a large data item into the 'small data' section making the section larger than 64k. 

 

If do a working link (small image array) and then look at the symbol table and linker map output file (you'll need to persuade the IDE to pass -Map file to ld) you should be able to work out why.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

That's not a matter of size. It seems the pointer used to reference the picture data bases on the current program counter, thus the code. How do you "include" the picture into you application?

0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

That's not a matter of size. It seems the pointer used to reference the picture data bases on the current program counter, thus the code. How do you "include" the picture into you application? 

--- Quote End ---  

 

 

I included it like that:# include "picture.h" 

 

and inside it: 

int pic_h = 60; 

int pic_w = 120; 

unsigned int pic[60][120]= 

{................}; 

 

and the calling like that :  

draw_array( 

(unsigned int *)pic, 

pic_w, 

pic_h, 

pic_viewer.display, 

((WIDTH-pic_w)/2), 

((HEIGHT-pic_h)/2), 

SPLASH_BG_MASK);
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

The linker must be putting your program sections together in an incorrect order. 

 

The 'small data' section is used for small data items (be default less than 8 bytes) so that they can be accessed using a signed 16bit offset from the 'global pointer' (gp) register instead of having to load the 32bit address for each access. 

 

So it looks as though the linker has put a large data item into the 'small data' section making the section larger than 64k. 

 

If do a working link (small image array) and then look at the symbol table and linker map output file (you'll need to persuade the IDE to pass -Map file to ld) you should be able to work out why. 

--- Quote End ---  

 

 

I will try this but how to persuade the IDE to pass MAP file to id??
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

Is the variable definition 

 

unsigned int pic[60][120] = { }; 

 

made inside of a function, i.e. main()?
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

Is the variable definition 

 

unsigned int pic[60][120] = { }; 

 

made inside of a function, i.e. main()? 

--- Quote End ---  

 

 

no the data of int pic[60][120] is initialized in the picture.h 

I noticed that when the size of pic exceeds some value the error happens below this value the picture comes out on the LCD without errors????
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

Maybe I should have been more precise. Is the variable pic[][] a global module variable or a local function variable?

0 Kudos
Altera_Forum
Honored Contributor II
650 Views

The output of 'objdump -h foo.o' and 'objdump -n foo.o' will show which sections the various pieces of data are assigned to. 

 

Your pic[] should end up in .data, pic_h and pic_w in .sdata. 

If they are correct there, then maybe something is stopping the linker merging all the .sdata sections together. 

 

Which version of gcc are you using?
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

Maybe I should have been more precise. Is the variable pic[][] a global module variable or a local function variable? 

--- Quote End ---  

 

 

I included the file pic.h inthe beginning of the main.c 

 

and the pic.h is like that: 

 

int pic_h = 40; 

int pic_w = 100; 

unsigned int pic[40][100]={ 

 

{16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215,16777215}, 

{16777215,.................... 

 

so I think it is a global variable.. 

0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

The output of 'objdump -h foo.o' and 'objdump -n foo.o' will show which sections the various pieces of data are assigned to. 

 

Your pic[] should end up in .data, pic_h and pic_w in .sdata. 

If they are correct there, then maybe something is stopping the linker merging all the .sdata sections together. 

 

Which version of gcc are you using? 

--- Quote End ---  

 

 

I am using version 10.0
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

That is the version of the Altera tools, not gcc :-) 

You might have gcc3 or gcc4. 

 

Both the gcc3 and gcc4 I've built from the sources on Altera's ftp site correctly put the array into .data. 

I don't think any of my patches affect it (one puts MORE stuff into .sdata). 

 

It is worth running objdump -h to see how big .data and .sdata are.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

That is the version of the Altera tools, not gcc :-) 

You might have gcc3 or gcc4. 

 

Both the gcc3 and gcc4 I've built from the sources on Altera's ftp site correctly put the array into .data. 

I don't think any of my patches affect it (one puts MORE stuff into .sdata). 

 

It is worth running objdump -h to see how big .data and .sdata are. 

--- Quote End ---  

 

 

really I donot run the application from the command shell..I am using the nios2 build tool for eclipse..so i donot understand all you are talking about, execuse me.. but the gcc version i think gcc4.. 

 

can I send you the sopcinfo file and the main.c??
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

I don't ever run the IDE! 

 

The IDE will have left the .o file lurking somewhere (probably polluting the directory with your sources). 

It also installs a copy of objdump somewhere. 

 

Everything is actually a lot easier to understand if you don't use an IDE - IDEs try to do everything for you by 'magic' and leave you without any of the knowlege required to find out what has really happened when things go wrong.
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

I don't ever run the IDE! 

 

The IDE will have left the .o file lurking somewhere (probably polluting the directory with your sources). 

It also installs a copy of objdump somewhere. 

 

Everything is actually a lot easier to understand if you don't use an IDE - IDEs try to do everything for you by 'magic' and leave you without any of the knowlege required to find out what has really happened when things go wrong. 

--- Quote End ---  

 

 

thank you .. 

but from where should I begin? 

and how can I fix this problem??
0 Kudos
Altera_Forum
Honored Contributor II
650 Views

 

--- Quote Start ---  

hello,mallocr.c:2150: warning: unable to reach (null) (at 0x0023814c) from the global pointer (at 0x0022addc) because the offset (54128) is out of the allowed range, -32678 to 32767. 

 

--- Quote End ---  

 

This (lamentably obscure) error message indicates overflow of the .sdata segment. By default (see -G n -- but use with extreme caution!) globals of size 8 bytes or less are assigned to .sdata, which is limited to 64KB (32KB in Nios2 toolchains before ACDS 14.1 iirc). The purpose of this is to allow these globals to be accessed via fast, compact 16-bit offsets from the GP register. Globals may also be assigned to .sdata using the gcc __attribute__ mechanism, which can result in faster or more compact code if used judiciously. The simplest (if not necessarily best) way to deal with .sdata overflow as above is to use the -mno-gpopt switch (available in Nios2 gcc 3.x toolchains and also in gcc 4.x starting with ACDS 14.1). This will eliminate the 64KB limit at the cost of generating slower less dense code which uses 32-bit offsets throughout to access these globals. Some might argue that using fewer globals is a better solution. :-)
0 Kudos
Reply