Why is there a compiler error when attempting to place two (RAM) variables, which only differ by their initialisation values, into the same section?
Problem
The C source:
int __attribute__((section(".in_my_data"))) _foo = 1;
int __attribute__((section(".in_my_data"))) _bar = 0;
The (relevant) GCC compiler output:
mcve/main.c:75:45: error: _bar causes a section type conflict
The linker script contains the following line in the SECTIONS
definition, but the (fatal) error is from the compiler, not the linker.
.my_data : { *(.in_my_data) } > data
Further Information
Changing the C source to permit the compiler to use two sections allows the compile to pass, but the linker then generates an error if the two input sections are mapped into the same output section.
The C source:
int __attribute__((section(".in_my_data_nonzero"))) _foo = 1;
int __attribute__((section(".in_my_data_zero"))) _bar = 0;
The linker script:
.my_data : { *(.in_my_data*) } > data
The (relevant) linker output:
Link Error: attributes for input section '.in_my_data_nonzero' conflict
with output section '.my_data'
Swapping the order of the lines in the C source only changes which section (the second to appear in the C source) is in error.
Question
What attribute(s) does the GCC compiler require of a section for a variable that is initialised with zero that it doesn't for one that is initialised with non-zero, or vice versa?
Is the compiler trying to place the variables that are initialised to zero in the .bss
section, rather than the .data
section for initialised data? Or is there another section for data that is initialised to zero?
Related questions
Similar questions appear cover issues with conflicts between memory types (ROM vs. RAM):
- "Section type conflict" in arm embedded, what is it?
- How do I resolve a "section type conflict" compile error and best practices for using section attribute with gcc
- Getting a "section type conflict" using M2tklib and glcd
... or putting initialised const
data in NOLOAD output sections:
- "Section type conflict" due to macro definition in GCC 4.8.2
... or remain a mystery as to the cause and may be related:
- Section type conflict for identically defined variables
None of the above appear to have an answer that I can apply to issue in this question, as far as I can tell.