Hi,
I noticed this behavior while working with an intel hex output. The ihex file contained two lines with overlapping data. As it seems objcopy just steps through the sections in the elf file and outputs those into the ihex file.
It seems the Segger linker (not x-checked with GNU) can generate overlapping section with the compressed initialized data and ro padding enabled:

From the map file:
000000c4-000000df __SEGGER_init_data__ 28 4 Cnst RO [ Linker created ]
000000e0-000000dd ( ALIGN .=.+4294967294 ) -2 - ---- - -
000000de-000000f1 __SEGGER_init_copy 20 2 Code RX SEGGER_crtinit_v8m_mainline_little.o

The last byte of __SEGGER_init_data__ overlaps with the first byte __SEGGER_init_copy. The align of .=.-2 also seems odd (or is the reason?).


Seen on emStudio 6.30 and 6.32a.

How to reproduce:
* Create new Cortex-M Project (core: Cortex-M33 - haven't tried others), everything else: default
* main.c (simply some initialized rw data that must be kept)
-----------
volatile char xx[] = {"abcdefgijklmnopqrstuvwxyz"};
int main(void)
{
xx[0]++;
}
-----------
* In the Linker Options: set Pad ro Section to Yes (everything is fine without his)
* Build (tested with Debug")

The linker gives no error or warning (I guess it's fine for him due to the wrong (?) "align").
Somehow this does not seem to be right or am I missing something?

Regards,
Clemens