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.
