GreenHills - small data area overflow

Question

I hope someone has a quick answer for this, but essentially, when I turn on optimization, I get the following error:

[elxr] (error) small data area overflow: 0xfff9f6fc (signature) not in 16 bits when executed moving to test_main.o file in the place __sti ___ 13_test_main_cpp_252229d3 + 0xc, to refer to the character oe_init_intconn

A similar error occurs when adding this linker directive:

-auto_sda

Their guide does not mention a linker error. I am using Integrity 5.10

Answer 1

This linker error is usually not related to optimizing -Olink -auto_sda . The compiler sees your entire program and tries not to spoil it with auto-creation for more than 64 thousand data. (This may be a linker error, but this is unlikely.)

This error usually occurs because someone who is not as shrewd as the linker already puts more than 64 Kbytes in the SDA partitions before the linker even gets a chance to go for it. You can be an unresponsive person if you did something like

 #pragma startsda int small_data[10000]; // 40Kbytes int small_data_also[10000]; // another 40Kbytes #pragma endsda 

(it’s possible to split it into several files, in fact, I think you will get the compiler or assembler diagnostics if you try to create more than 64 Kbytes of SDA in one file).

But an unpromising person can also be a compiler if you pass parameters like -sda=4 (which acts as if you select #pragma startsda for each global variable of 4 bytes or everything in the whole file) and you have a ton global variables. The compiler will happily SDAize 10,000 bytes in each of the 20 separate files, and then the linker will complain that you are transferring 200,000 bytes of SDA to it. (The linker is smart enough to rewrite regular links to data in SDA links, but never learned to rewrite things in the opposite direction.)

Finally, even if you think you do not pass -sda= , you may be surprised. Run the driver with the option -# or -v . IIRC, ccintppc secretly passes -sda=4 by default. You can make the driver stop "helping" you; just go -sda=none or -sda=0 , which should override the default driver. You might want to pass this option on each, starting with your coolest code .

Answer 2

After some research, it is possible that linking libraries that all do not use the SDA parameter may have this conflict. Since I have no control over how these libraries are created, at the moment I applied the following flags to my GPJ, which seemed to solve the problem:

 -Onolink -no_auto_sda -nothreshold 

Please note that these options disable all linker optimizations and completely disable the SDA option.

Answer 3

I had the same problem, this should also fix this for you:

The -large_sda compiler -large_sda allows you to use 23-bit SDA relay instead of 16-bit. Then you can also use -sda=all without any problems.