This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I just tried out the latest packaged release of MSP430 GCC (v3.2.2.0) and I noticed that as of this version, uninitialized global variables end up getting placed in .noinit rather than .bss. This was not the case in the previous release, v2.1.1.0
Why the change? As I understand it, The C99 standard specifies that global variables that are not explicitly initialized get set to 0, ie placed in .bss
I am unable to reproduce this problem. I tried this very simple example ...
int global; int main() { return global; }
With both compiler versions, the variable global ends up in the .bss section.
Please supply a test case which shows global variables ending up in the .noinit section. Please include the exact compiler options used.
Thanks and regards,
-George
I have narrowed it down further. Looks like it is not an issue with the compiler, but related to a change in the linker scripts. In my case, I saw the issue when building for MSP430F5529.
Using the simple example you specified, the following commands will recreate the issue:
D:/programs/mspgcc_ti_3.2.2.0/bin/msp430-elf-gcc -mmcu=msp430f5529 -T D:/programs/mspgcc_ti_3.2.2.0/include/msp430f5529.ld -o gcc_bug.elf main.c
D:/programs/mspgcc_ti_3.2.2.0/bin/msp430-elf-objdump -t -j .bss -j .noinit gcc_bug.elf > gcc_bug.txt
The resulting txt file:
gcc_bug.elf: file format elf32-msp430
SYMBOL TABLE:
0000247e l d .bss 00000000 .bss
00002490 l d .noinit 00000000 .noinit
0000247e l O .bss 00000001 completed.2761
00002480 l O .bss 00000002 dtor_idx.2763
00002482 l O .bss 0000000e object.2776
00002490 g O .noinit 00000002 global
0000247e g .bss 00000000 __bssstart
00004400 g .noinit 00000000 __stack
00002492 g .noinit 00000000 _end
If I force it to use the old linker script (from 2.1.1.0) the "global" symbol is mapped to bss correctly. I tried a 1xx-series device and it worked fine too.
Your analysis is correct. This is an error in the linker script. The COMMON section is incorrectly placed in .noinit. It should go in .bss. I filed an issue with the development team that maintains those scripts. Using the older linker scripts is a reasonable workaround.
Thanks and regards,
-George