[Bug target/58695] MSP430 zero-initialized array remains uninitialized with -nostartfiles
quandary at remstate dot com
gcc-bugzilla@gcc.gnu.org
Fri Oct 11 23:37:00 GMT 2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58695
--- Comment #2 from Travis Snoozy <quandary at remstate dot com> ---
(In reply to Andrew Pinski from comment #1)
> I think you should do either -fno-zero-initialized-in-bss or even better use
> a linker script which forces the bss to be allocated in memory.
Thanks; I didn't know about -fno-zero-initialized-in-bss for now, and it neatly
works around this problem for now.
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.
Would it be possible to have -nostartfiles automatically imply
-fno-zero-initialized-in-bss, because the former changes how .bss will
effectively behave?
More information about the Gcc-bugs
mailing list