4

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

Gary
  • 1,515
  • 1
  • 14
  • 22
  • btw, the only thing I did come across was a mention that there might be some kind of incompatibility between libraries build using sda and those that weren't. – Gary May 07 '10 at 11:36

3 Answers3

5

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.

Quuxplusone
  • 23,928
  • 8
  • 94
  • 159
  • I can't confirm it =), I switched jobs but it sounds more detailed as to the root cause than my high level fix. – Gary Feb 05 '13 at 15:13
  • @Quuxplusone I have disabled SDA but it didn't solve the problem. I'm using GHS Multi IDE not from command line. Do you know how to use -v option. Thanks – The Beast Oct 21 '16 at 10:46
  • @Frankenstein: If your error message differs in any way from Gary's, please post a new question and link to it from a comment here. If you're getting literally the same error message (down to the reference to `oe_init_intconn`), then (a) I don't believe you, and (b) you just add `-v` to your compiler options, that's all. – Quuxplusone Oct 21 '16 at 18:27
  • @Quuxplusone Already done =D http://stackoverflow.com/questions/40174361/error-read-only-small-data-overflow-in-ghs-compiler Not exactly the same error message. But also i'm using GHS Multi wich is a GUI interface not from the command line – The Beast Oct 21 '16 at 18:37
1

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.

Gary
  • 1,515
  • 1
  • 14
  • 22
  • Note, initially I'm not accepting this answer as its not the best and would welcome any improved ideas that would still allow optimizations. – Gary May 12 '10 at 11:31
  • I think I've posted the real answer, although I know it's two years too late. ;) – Quuxplusone Sep 06 '12 at 18:05
0

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.

Noel Widmer
  • 4,444
  • 9
  • 45
  • 69
cruano
  • 1