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

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

[quandary at remstate dot com]

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

            Bug ID: 58695
           Summary: MSP430 zero-initialized array remains uninitialized
                    with -nostartfiles
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: quandary at remstate dot com

Created attachment 30986
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30986&action=edit
Should initialize a 16-byte array to all zeroes

When initializing (non-constant) arrays with a list of constants, an all-zero
array is left uninitialized when -nostartfiles is specified. Arrays with any
non-zero elements are still initialized properly.

At the assembly level, the difference in behavior seems to be that the compiler
puts all-zero arrays into .bss, whereas the compiler puts arrays with non-zero
elements into .data. I would suggest that in the case where -nostartfiles is
specified, an explicit all-zero array should be placed into .data so that
initialization/programming takes place per the programmer's intent.


msp430-elf-gcc -v:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/msp430-elf/gcc-bin/9999/msp430-elf-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/msp430-elf/9999/lto-wrapper
Target: msp430-elf
Configured with:
/var/tmp/portage/cross-msp430-elf/gcc-9999/work/gcc-9999/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/msp430-elf/gcc-bin/9999
--includedir=/usr/lib/gcc/msp430-elf/9999/include
--datadir=/usr/share/gcc-data/msp430-elf/9999
--mandir=/usr/share/gcc-data/msp430-elf/9999/man
--infodir=/usr/share/gcc-data/msp430-elf/9999/info
--with-gxx-include-dir=/usr/lib/gcc/msp430-elf/9999/include/g++-v9999
--host=x86_64-pc-linux-gnu --target=msp430-elf --build=x86_64-pc-linux-gnu
--disable-altivec --disable-fixed-point --without-cloog --disable-lto
--enable-nls --without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib --disable-libmudflap
--disable-libssp --disable-libgomp
--with-python-dir=/share/gcc-data/msp430-elf/9999/python
--enable-poison-system-directories --enable-checking=release --disable-libgcj
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--disable-libquadmath --enable-languages=c --disable-shared --disable-libatomic
--disable-threads --without-headers --disable-bootstrap --with-newlib
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN'
Thread model: single
gcc version 9999 20131011 (experimental) rev. 203465 (Gentoo SVN) 


Command line that triggers the bug:

msp430-elf-gcc -save-temps -nostartfiles -o bug.elf zero_init.c

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

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

[quandary at remstate dot com]

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?

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

[pinskia at gcc dot gnu.org]

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.