problem with code size"need help"

[Altera_Forum]

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??   

[Altera_Forum]

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.

[Altera_Forum]

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?

[Altera_Forum]

--- 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);

[Altera_Forum]

--- 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??

[Altera_Forum]

Is the variable definition 

 unsigned int pic[60][120] = { };   made inside of a function, i.e. main()?

[Altera_Forum]

--- 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????

[Altera_Forum]

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

[Altera_Forum]

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?

[Altera_Forum]

--- 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.. 

[Altera_Forum]

--- 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

[Altera_Forum]

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.

[Altera_Forum]

--- 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??

[Altera_Forum]

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.

[Altera_Forum]

--- 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??

[Altera_Forum]

--- 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. :-)