GreenHills - small data area overflow

Question

I'm hoping maybe someone has a quick answer for this but essentially when I turn on optimizations, I get the following error:

[elxr] (error) small data area overflow: 0xfff9f6fc (signed) didn't fit in 16 bits while performing relocation in file test_main.o at location __sti___13_test_main_cpp_252229d3+0xc, to reference symbol oe_init_intconn

A similar error occurs when I put in this linker directive as well:

-auto_sda

Their manual doesn't make any mention of this linker error. I'm using Integrity 5.10

Answer 1

This linker error is usually not related to the -Olink optimization -auto_sda. The linker sees your whole program and will try not to screw it up by autoSDAizing more than 64K of your data. (It might still be a linker bug, but that's unlikely.)

This error usually happens because someone who is not as perceptive as the linker has already put more than 64K bytes into SDA sections before the linker even gets a chance to have a go at it. The unperceptive individual might be you, if you did something like

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

(possibly split across multiple files; in fact I think you'll get a compiler or assembler diagnostic if you try to create more than 64K of SDA in a single file).

But the unperceptive individual might also be the compiler, if you're passing options such as -sda=4 (which acts as if you threw a #pragma startsda around every global variable of 4 bytes or smaller in the entire file) and you have a ton of global variables. The compiler will happily SDAize 10,000 bytes in each of 20 individual files, and then the linker will complain that you're handing it 200,000 bytes of SDA. (The linker is smart enough to rewrite regular data references into SDA references, but has never been taught how to rewrite things in the opposite direction.)

Finally, even if you think you're not passing -sda=, you might be surprised. Run the driver with the -# or -v option. IIRC, ccintppc secretly passes -sda=4 by default. You can get the driver to stop "helping" you; just pass -sda=none or -sda=0, which should override the driver's default. You might want to pass this option on a file-by-file basis, starting with your coldest code.

Answer 2

After doing some research, it's possible that linking libraries that all don't use the SDA option might have this conflict. Since I don't have control over how those libraries are built, at the moment I've applied the following flags to my GPJ that seemed to resolve the issue:

-Onolink
-no_auto_sda
-nothreshold

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

Answer 3

I had the same issue, this should fix it for you too:

The compiler option -large_sda will allow 23-bit SDA relocations instead of 16bits. Then you should also be able to use -sda=all without problems.