[En-Nut-Discussion] cortex_init.c breaks strict-aliasing rules

[Philipp Burch]

Hi all,

when compiling Ethernut using the GCC built as described in [1], I get 
the following errors (warnings) as soon as optimizations are turned on:

------- 8< --------- 8< ----------
23:23:23: arm-none-eabi-gcc -c -I/home/.../nutbld-lm3s/include 
-I/home/.../nut/include  -DDK_LM3S9B96  -MD -MP -mcpu=cortex-m3 -mthumb 
-mlittle-endian -D__CORTEX__ -ffunction-sections -fdata-sections 
-fomit-frame-pointer -mfix-cortex-m3-ldrd -Os -Wall -Wstrict-prototypes 
-Werror -Wa,-a=cm3/cmsis/cortex_init.lst  -DDK_LM3S9B96 -o 
cm3/cmsis/cortex_init.o /home/.../nut/arch/cm3/cmsis/cortex_init.c
23:23:23: cc1: warnings being treated as errors
/home/.../nut/arch/cm3/cmsis/cortex_init.c: In function 'Cortex_Start':
/home/.../nut/arch/cm3/cmsis/cortex_init.c:251: error: dereferencing 
pointer 'src' does break strict-aliasing rules
/home/.../nut/arch/cm3/cmsis/cortex_init.c:247: note: initialized from here
/home/.../nut/arch/cm3/cmsis/cortex_init.c:251: note: initialized from here
/home/.../nut/arch/cm3/cmsis/cortex_init.c:251: error: dereferencing 
pointer 'dst' does break strict-aliasing rules
/home/.../nut/arch/cm3/cmsis/cortex_init.c:249: note: initialized from here
/home/.../nut/arch/cm3/cmsis/cortex_init.c:251: note: initialized from here
/home/.../nut/arch/cm3/cmsis/cortex_init.c:258: error: dereferencing 
pointer 'dst' does break strict-aliasing rules
/home/.../nut/arch/cm3/cmsis/cortex_init.c:256: note: initialized from here
/home/.../nut/arch/cm3/cmsis/cortex_init.c:258: note: initialized from here
------- 8< --------- 8< ----------

The compiler's -v output:

------- 8< --------- 8< ----------
devnut_lm3s$ arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-bare_newlib_cortex_m3_nommu-eabi
Configured with: 
/home/phip/x-tools/arm-eabi/.build/src/gcc-4.4.1/configure 
--build=x86_64-build_unknown-linux-gnu 
--host=x86_64-build_unknown-linux-gnu 
--target=arm-bare_newlib_cortex_m3_nommu-eabi 
--prefix=/home/phip/x-tools/arm-bare_newlib_cortex_m3_nommu-eabi 
--with-local-prefix=/home/phip/x-tools/arm-bare_newlib_cortex_m3_nommu-eabi/arm-bare_newlib_cortex_m3_nommu-eabi/sysroot 
--disable-libmudflap 
--with-sysroot=/home/phip/x-tools/arm-bare_newlib_cortex_m3_nommu-eabi/arm-bare_newlib_cortex_m3_nommu-eabi/sysroot 
--with-newlib --enable-threads=no --disable-shared 
--with-pkgversion='crosstool-NG 1.15.3' --with-cpu=cortex-m3 
--with-tune=cortex-m3 --with-float=soft --disable-__cxa_atexit 
--with-gmp=/home/phip/x-tools/arm-eabi/.build/arm-bare_newlib_cortex_m3_nommu-eabi/buildtools 
--with-mpfr=/home/phip/x-tools/arm-eabi/.build/arm-bare_newlib_cortex_m3_nommu-eabi/buildtools 
--with-ppl=/home/phip/x-tools/arm-eabi/.build/arm-bare_newlib_cortex_m3_nommu-eabi/buildtools 
--with-cloog=/home/phip/x-tools/arm-eabi/.build/arm-bare_newlib_cortex_m3_nommu-eabi/buildtools 
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic 
-lm' --enable-target-optspace --disable-libgomp --disable-libmudflap 
--disable-nls --disable-multilib --enable-languages=c,c++ --with-mode=thumb
Thread model: single
gcc version 4.4.1 (crosstool-NG 1.15.3)
------- 8< --------- 8< ----------

When using the cm3-gccdbg target in the configurator, everything is 
fine. Interestingly, if I compile using the eCross toolchain, there is 
no problem with either option (debug or release). It has this -v output:

------- 8< --------- 8< ----------
devnut_lm3s$ arm-eCross-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-eCross-eabi-gcc
COLLECT_LTO_WRAPPER=/home/phip/Desktop/arm-eCross-eabi/bin/../libexec/gcc/arm-eCross-eabi/4.5.2/lto-wrapper
Target: arm-eCross-eabi
Configured with: ../src/gcc-4.5.2/configure --target=arm-eCross-eabi 
--prefix=/home/ole/work/eCross/arm-eCross-eabi --disable-nls 
--disable-shared --disable-threads --with-gcc --with-gnu-ld 
--with-gnu-as --with-dwarf2 --enable-languages=c,c++ --enable-interwork 
--enable-multilib --with-newlib 
--with-headers=../src/newlib-1.19.0/newlib/libc/include --disable-libssp 
--disable-libstdcxx-pch --disable-libmudflap --disable-libgomp 
--with-system-zlib --enable-lto -v
Thread model: single
gcc version 4.5.2 (GCC)
------- 8< --------- 8< ----------

The offending code is in the obviously inlined function Cortex_MemInit():

------- 8< --------- 8< ----------
static void Cortex_MemInit(void)
{
     register uint32_t *src, *dst, *end;
     register uint32_t fill = 0;

     /*
      * Plain C-Code Cortex Init
      */

     /* Copy the data segment initializers from flash to SRAM. */
     src = (uint32_t*)&_etext;
     end = (uint32_t*)&_edata;
     for( dst = (uint32_t*)&_sdata; dst < end;)
     {
         *dst++ = *src++;      /* Line 251 */
     }

     /* Fill the bss segment with 0x00 */
     end = (uint32_t*)&_ebss;
     for( dst = (uint32_t*)&_sbss; dst < end; )
     {
         *dst++ = fill;        /* Line 258 */
     }

     __set_PSP((uint32_t)&_pspstack_end);
}
------- 8< --------- 8< ----------

How could this be solved? _etext and friends are declared this way:

------- 8< --------- 8< ----------
extern void * _etext;           /* Start of constants in FLASH */
extern void * _sidata;          /* Start of variables in FLASH */
extern void * _sdata;           /* Start of variables in RAM */
extern void * _edata;           /* End of variables in RAM */
extern void * _sbss;            /* Start of unset variables in RAM */
extern void * _ebss;            /* End of unset variables in RAM */
------- 8< --------- 8< ----------

So these are of type void*, while MemInit() uses uint32_t*. What's the 
point of declaring them as void* in the first place? Is that required 
because they are defined in the linker file with some (unknown) type?

Anyway, if I change the declaration to uint32_t*, the errors are still 
there. But then I see something else: _etext is already a pointer and 
Cortex_MemInit() takes the variable's address (&_etext). How can this 
work? In my opinion, this would result in a type void**, which is then 
casted to uint32_t*.

Is there anyone who could clarify this for me?

Thanks,
Philipp

[1] 
http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/t/65137.aspx