Resolution: make -fno-zero-initialized-in-bss the default behavior and force uninitialized data objects into .bss to match TI proprietary behavior with respect to zero-initialized data objects

The current tiarmclang compiler uses -fzero-initialized-in-bss by default, which instructs the compiler to allocate zero-initialized data objects into the .bss section with the expectation that the .bss output section will be zero-initialized either by the linker, the loader, or at run-time.

This is not default behavior for the linker and when the RAM auto-initialization model (-cr linker option) is used, the linker will not generate .cinit records for zero-initialized data.

A potential fix to this issue is to make -fno-zero-initialized-in-bss the default behavior for clang, but this has the effect of also defining uninitialized data objects in initialized .data sections (using .section directive with %progbits operand). This does not match armcl behavior and may introduce discontinuities for developers that are trying to migrate their armcl project to tiarmclang.

To make the clang default behavior more similar to armcl with respect to zero-initialized and uninitialized data objects, the proposed fix is:

• make -fno-zero-initialized-in-bss the default behavior for tiarmclang, but
• add an additional command-line option, -fdef-uninit-in-bss, that is on by default and forces uninitialized data objects to be defined in .bss as they would have been had -fzero-initialized-in-bss been set.