[Bug target/58695] MSP430 zero-initialized array remains uninitialized with -nostartfiles

pinskia at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sat Oct 12 00:35:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58695

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Travis Snoozy from comment #2)
> I don't see how the linker script can be the problem here -- perhaps I'm
> missing a point? Looking at my output, .bss and its variables *are*
> allocated in memory -- the symbol shows up, the space is blocked out for
> use. The problem is that an initialized value shouldn't be going into .bss
> in the first place, because .bss (by definition) *uninitialized* memory.
> Because I have -nostartfiles, the uninitialized memory is remaining
> uninitialized, instead of being cleared.

Because the .bss is consider as zero initialized by the ELF standard.  If your
loader does not zero initialize it, then your runtime is supposed to take care
of it.  If neither of these two things happen, then you have the issue you are
pointing out.  It is an issue in your code not initializing the BSS section to
zero rather than a bug in GCC assuming it will be allocated as zero.

A linker script fixes the problem by loading it from the executable file.



More information about the Gcc-bugs mailing list