• Status Unconfirmed
  • Percent Complete
  • Ticket Type Bug Report
  • Category
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Normal
  • Reported Version 1.10
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: EmBitz IDE
Opened by (t.lang) - 2018-04-06

Ticket#290 - Generated linker files are broken regarding data segment handling

with a current project I just stumbled over a bug in the generated linker scripts again: Typically the .data section part looks like this:

__etext = .;
.data : AT (__etext)
__data_start__ = .;
. = ALIGN(4);
/* All data end */
__data_end__ = .;
} > RAM

The problem with this version is that the linker will not detect ROM overflows caused by the intialization data. I observed this first with some other ARM project in the past where the compiled software crashed during start due to such an overflow.

The working version is as follows:
__etext = .;
__data_start__ = .;
. = ALIGN(4);
/* All data end */
__data_end__ = .;
} > RAM AT > ROM

You can easily test this by reducing the ROM size in the linker file to somewhat slightly greater than the code size of your project and then e. g. creating a large initialized array which still fits into the RAM, e. g. (assuming that you have more than 16K RAM left):

volatile uint8_t DummyArray[16384] = {1,2,3,4,5,6,7,8,9,10};
int main(void)
DummyArray[16383] = 1;

In my current case the target is an STM32F103 where my code is about 46K and where I reduced the ROM size to 50K. With the broken linker script ld happily links the project and I get the resulting map file (excerpt):

*(.ARM.extab* .gnu.linkonce.armextab.*)
0x0800b638 __exidx_start = .
.data 0x20000000 0x4088 load address 0x0800b640
0x20000000 __data_start__ = .
.bss 0x20004088 0x1a08 load address 0x0800f6c8
0x20004088 __bss_start__ = .

As you can clearly see there is a ROM overflow (0x0800b638 + 0x4088 = 0x800f6c0 while the configured ROM size is 0xC800), so more than 11K are linked behind the configured ROM end.

This bug is quite nasty as you will get the correct (and same) results as long as the initialization data fit but depending on the memory organization you will get strange bugs regarding the intialized data.

This ticket does not depend on any other tickets.

Friday, 06 April 2018, 13:03 GMT
Regarding the last sentence: If access beyond the ROM leads to an exception the software will run into the hardfault handler during initialization which is good as it is obvious that there's something wrong. With the STMs there is the problem that the smaller devices may have more RAM or ROM as documented in the data sheets, so the software even may run without errors but uses memory that is not tested during production. And the last case may be that the addresses behind the ROM are readable and deliver some random data. In this case part of the data will be initialized with more or less random data which may not prevent the software from starting but most likely will lead to strange effects.