[ELDK] GCC anomaly

Bernhard Weirich bernhard.weirich at riedel.net
Wed Apr 23 10:37:56 CEST 2008


Hello,

I use binary ELDK 4.2 distribution with the ppc_4xx-gcc configured as:

Reading specs
from /opt/eldk/usr/bin/../lib/gcc/powerpc-linux/4.2.2/specs
Target: powerpc-linux
Configured
with: /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/configure --target=powerpc-linux --host=i686-host_pc-linux-gnu --prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux --disable-hosted-libstdcxx --with-headers=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux/include --with-local-prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared --enable-c99 --enable-long-long --without-x
Thread model: posix
gcc version 4.2.2

When I compile the following code with -Os then ppc_4xx-gcc generates an
infinite loop for the ebc_load function!

int main()
{
        nand_boot();
}

static void ebc_load(unsigned int *src, int uboot_size, unsigned int
*dst)
{
        uboot_size /= 4;
        while(uboot_size > 0)
        {
                *(dst++) = *(src++);
                uboot_size--;
        }
}
#define initdram(x)     0

#define CFG_NAND_U_BOOT_SRC     0xfffa0000
#define CFG_NAND_U_BOOT_DST     0x01000000
#define CFG_NAND_U_BOOT_SIZE    (384 << 10)
#define CFG_NAND_U_BOOT_START   CFG_NAND_U_BOOT_DST

void nand_boot(void)
{
        int ret;
        void (*uboot)(void);

        ebc_load((unsigned int *) CFG_NAND_U_BOOT_SRC,
CFG_NAND_U_BOOT_SIZE, (unsigned int *)CFG_NAND_U_BOOT_DST);

        /*
         * Jump to U-Boot image
         */
        uboot = (void (*)(void))CFG_NAND_U_BOOT_START;
        (*uboot)();
}

The dissassembly of nand_boot looks like the following:

100003c0 <nand_boot>:
100003c0:	3d 60 ff fa 	lis     r11,-6
100003c4:	80 0b 00 00 	lwz     r0,0(r11)
100003c8:	3d 2b 01 06 	addis   r9,r11,262
100003cc:	39 6b 00 04 	addi    r11,r11,4
100003d0:	90 09 00 00 	stw     r0,0(r9)
100003d4:	4b ff ff f0 	b       100003c4 <nand_boot+0x4>

That infinite loop should not be there!!

I tried compiling with the gcc built by buildroot and it works as
expected.
Target: powerpc-linux-uclibc
Configured
with: /home/bernhard/svn/Firmware/Rootfilesys/root_080410/toolchain_build_powerpc/gcc-4.2.3/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=powerpc-linux-uclibc --enable-languages=c,c++ --with-sysroot=/home/bernhard/svn/Firmware/Rootfilesys/root_080410/build_powerpc/staging_dir --with-build-time-tools=/home/bernhard/svn/Firmware/Rootfilesys/root_080410/build_powerpc/staging_dir/usr/powerpc-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/bernhard/svn/Firmware/Rootfilesys/root_080410/toolchain_build_powerpc/gmp --with-mpfr=/home/bernhard/svn/Firmware/Rootfilesys/root_080410/toolchain_build_powerpc/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=405 --disable-largefile
Thread model: posix
gcc version 4.2.3

10000330 <nand_boot>:
10000330:	94 21 ff f0 	stwu    r1,-16(r1)
10000334:	7c 08 02 a6 	mflr    r0
10000338:	3d 40 00 01 	lis     r10,1
1000033c:	90 01 00 14 	stw     r0,20(r1)
10000340:	61 4a 80 00 	ori     r10,r10,32768
10000344:	3d 60 ff fa 	lis     r11,-6
10000348:	35 4a ff ff 	addic.  r10,r10,-1
1000034c:	80 0b 00 00 	lwz     r0,0(r11)
10000350:	3d 2b 01 06 	addis   r9,r11,262
10000354:	90 09 00 00 	stw     r0,0(r9)
10000358:	39 6b 00 04 	addi    r11,r11,4
1000035c:	40 a2 ff ec 	bne-    10000348 <nand_boot+0x18>
10000360:	3c 00 01 00 	lis     r0,256
10000364:	7c 09 03 a6 	mtctr   r0
10000368:	4e 80 04 21 	bctrl
1000036c:	80 01 00 14 	lwz     r0,20(r1)
10000370:	38 21 00 10 	addi    r1,r1,16
10000374:	7c 08 03 a6 	mtlr    r0
10000378:	4e 80 00 20 	blr

I can hardly believe that this is a gcc bug, but if it is it might be
worth releasing a fixed eldk with an updated gcc.

Schöne Grüße,
Bernhard


More information about the eldk mailing list