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

Sun Dec 9 16:50:56 CET 2012

Anyone?

Regards,
Philipp

On 11/10/2012 11:58 PM, Philipp Burch wrote:
> 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
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>