causes partition type conflict" Why does a compiler error occur when trying to put two (RAM) variables that differ only in th...">
Geek Answers Handbook

GCC error "<variable> causes partition type conflict"

Why does a compiler error occur when trying to put two (RAM) variables that differ only in their initialization values ​​in the same section?

Problem

Source C:

int __attribute__((section(".in_my_data"))) _foo = 1; int __attribute__((section(".in_my_data"))) _bar = 0;

GCC compiler output (relevant):

 mcve/main.c:75:45: error: _bar causes a section type conflict

The script component contains the following line in the SECTIONS definition, but the (fatal) error comes from the compiler, not from the linker.

 .my_data : { *(.in_my_data) } > data

Additional Information

Changing the C source that allows the compiler to use two partitions allows the compiler to go through, but then the linker generates an error if the two input sections are mapped to the same output section.

Source C:

 int __attribute__((section(".in_my_data_nonzero"))) _foo = 1; int __attribute__((section(".in_my_data_zero"))) _bar = 0;

Component script:

 .my_data : { *(.in_my_data*) } > data

Relay output (relay):

 Link Error: attributes for input section '.in_my_data_nonzero' conflict with output section '.my_data'

When replacing the row order in source C, only that section (the second that appears in source C) changes in error.

Question

What attributes does the GCC compiler need for a section for a variable that is initialized to zero, that it is not for one that is initialized to non-zero, or vice versa?

Does the compiler try to put variables that are initialized to zero in the .bss section, and not in the .data section for initialized data? Or is there another section for data that is initialized to zero?

Related Questions

Similar questions arise with problems with conflicts between memory types (ROM and RAM):

  • The "partition type context" in hand is embedded, what is it?
  • How to resolve section type conflict "compile error and recommendations on using section attribute with gcc
  • Getting Type Conflict Type Using M2tklib and glcd

... or by placing the initialized const data in the NOLOAD output sections:

  • "partition type conflict" due to macro definition in GCC 4.8.2

... or remain secret about the reason and may be related:

  • Section type context for identically defined variables

None of the above questions contains an answer that I can apply to the question in this question, as far as I can tell.

+7
c gcc xc16
source share
2 answers

Caution: this answer can only be applied to the Microchip XC16 compiler.

Research

The compiler assigns attributes to the C variables so that they are distributed into specific sections as follows (see Note 1 below for specific XC16 information).

  • int a = 1; - assigned to .data .
  • int b = 0; - assigned to .bss .
  • int c; - assigned to .bss .

The first and last of them make sense: .data used for initialized data, and .bss used for uninitialized data. However, .bss data is also set to zero by running ANSI C (see Note 2).

Answer

It seems that the compiler includes variables that are initialized, but with a value that is equal to all bits 0 in the .bss section, as well as all those that are not initialized at all.

According to wikipedia :

An implementation can also assign statically assigned variables and constants, initialized to a value consisting solely of zero bits in the BSS section.

Bypass

GCC has the -fno-zero-initialized-in-bss , which can be used to force all -fno-zero-initialized-in-bss variables to be initialized to a .data section, as mentioned in this answer . This can be applied to the source file, but not to individual variables.

Desired Thinking

It would be nice if there was __attribute__((**doload**)) that could be used to force the compiler to put a null initialized variable in .data instead of .bss .

Notes

Note 1: The XC16 compiler can use .ndata and .nbss to indicate the closest data below address 0x8000.

Note 2. Labeling a variable with __attribute__((noload)) will exclude the variable from the .bss section. The XC16 generates a specific output section with a unique name (GUID?) For each variable marked as such.

+7
source share

By default, GCC puts object classes in different sections, executable code goes into .text, initialized data in .data, static data in .bss, and some more obscure ones.

If you try to make two objects of another class belong to the same section, GCC will raise this section error.

The solution is to put them in different sections and, finally, tell the linker to eventually combine these objects in the same section, for example:

 .boot : { // target ELF section will contain.... *(.boot) // executable code *(.boot_rodata) // constant data *(.boot_bss) // static data } > BOOT // to finally be place in this area
+5
source share

More articles:


All Articles