Sender: brian AT mnmai05 DOT mn DOT mediaone DOT net Message-ID: <3977B4C8.E8BF9841@mn.mediaone.net> Date: Thu, 20 Jul 2000 21:26:16 -0500 From: Brian Foddy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16-9mdksmp_bkf i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.os.linux.mandrake,comp.os.linux.misc To: pgcc AT delorie DOT com CC: bfoddy AT mn DOT mediaone DOT net Subject: Problems compiling kernel with pgcc 2.95.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: pgcc AT delorie DOT com For days now I have been having problems compiling the linux 2.2.16 (Mandrake 7.1) kernel with Pentium optimization on pgcc 2.95.2. Serious problems as I will describe below. I've done quite a bit of experimentation and internet browsing trying to find similar reports and I haven't been able to. To be honest, I find my own results difficult to believe myself (that if they are true that nobody else has reported this). BTW, I'm a long-time linux user and have successfully built many kernels. Also, I understand there is no promise pgcc will work for a kernel compile, but I think you will find my results interesting anyway. So bare with me... At a high level, I have Mandrake 7.1 running on a PII-450 (dual) with pgcc 2.95.2 loaded. I am trying to build a kernel on this machine for a Pentium 100 (no MMX) running Mandrake 6.1. The result of every normal compile is a kernel that will not boot. I see the loading message after lilo with most of the dots, then the machine reboots. I never see the uncompressing message or any other part of a normal linux boot. I posted an early version of this report on comp.os.linux.misc and received some suggested make options, but they didn't change the result. BTW, I'm being careful when I transfer the kernel between machines to use either binary ftp or nfs, and I rerun lilo each time after installing the kernel. I have not loaded the new compiler on the Pentium or vice versa to see if that has any effect. I am using the following special compile options: -O3, -march=pentium, -mcpu=pentium, -mpentium. The full compile line from one example module is : gcc -D__KERNEL__ -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include -Wall -Wstrict-prototypes -O3 -march=pentium -mcpu=pentium -ffast-math -funroll-loops -fomit-frame-pointer -fforce-mem -fforce-addr -malign-double -fno-exceptions -fno-strict-aliasing -pipe -O3 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s -mpentium -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations -mpentium -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -c -o init/main.o init/main.c I've also tried -O6 and -O2 with the same results. If I use the standard gcc compiler (2.95.3) the kernel build works. If I use pgcc 2.91.66 which is running on the Pentium, it works also. In both cases the exact same .config and make files. Also, if I build a PentiumPro kernel for the P2, it seems to work fine also. OK, now here's the detailed part. Because the kernel never even gets loaded properly I took an educated guess that there might be a problem with the last few steps of the build process. So I focused on those steps. I performed a normal build with pgcc and stripped off the last page of the make file output. After a few minor modifications to the output I obtained a simple shell script that performs the same last steps so I could experiment in more detail. My result is the following shell script which I run from arch/i386/boot of the build tree: #!/bin/bash GCC_NEW=/usr/local/pgcc/bin/gcc.color GCC_OLD=/usr/bin/gcc.colorgcc $GCC_NEW -D__KERNEL__ -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include -E -D__BIG_KERNEL__ -traditional -DSVGA_MODE=NORMAL_VGA bootsect.S -o bbootsect.s as86 -0 -a -o bbootsect.o bbootsect.s ld86 -0 -s -o bbootsect bbootsect.o $GCC_NEW -D__KERNEL__ -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include -E -D__BIG_KERNEL__ -traditional -DSVGA_MODE=NORMAL_VGA setup.S -o bsetup.s as86 -0 -a -o bsetup.o bsetup.s ld86 -0 -s -o bsetup bsetup.o cd /usr/src/linux-2.2.16.murdock/linux-2.2.16/arch/i386/boot/compressed tmppiggy=_tmp_$$piggy; \ rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk; \ objcopy -O binary -R .note -R .comment -S /usr/src/linux-2.2.16.murdock/linux-2.2.16/vmlinux $tmppiggy; \ gzip -f -9 < $tmppiggy > $tmppiggy.gz; \ echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}" > $tmppiggy.lnk; \ ld -m elf_i386 -m elf_i386 -r -o piggy.o -b binary $tmppiggy.gz -b elf32-i386 -T $tmppiggy.lnk; \ rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk #$GCC_NEW -D__KERNEL__ -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include -traditional -c head.S $GCC_OLD -D__KERNEL__ -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include -O2 -DSTDC_HEADERS -c -o misc.o misc.c $GCC_NEW -D__KERNEL__ -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include -O2 -DSTDC_HEADERS -c -o misc.o misc.c ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o cd .. $GCC_NEW -o tools/build tools/build.c -I/usr/src/linux-2.2.16.murdock/linux-2.2.16/include objcopy -O binary -R .note -R .comment -S compressed/bvmlinux compressed/bvmlinux.out tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage You will recognize this as the final steps of the build bzImage output, with the small addition that I can switch which compiler is used at each gcc step, either GCC_NEW = the pgcc compiler or GCC_OLD = standard gcc; I use colorgcc as a wrapper to both hence the funny names. What I found was that I can compile all modules with the pgcc compiler except the misc.c and have a working kernel. For misc.c I have to switch to the standard gcc compiler (GCC_OLD). Misc.c is a relatively small 358 line module that is part of the kernel wrapper executed right after the lilo selection and attempts to uncompress the kernel (at least I've gathered from the source). The shell script above will produce a working kernel, but if I use GCC_NEW at the misc.c line it won't work. So, go figure. Has anyone else seen this? I have noticed Mandrake 7.1 didn't include pgcc, anything to that? Is there a bug in the compiler? As you can see, I've spent a lot of time working on this and I'd really like to put it to bed one way or the other. Its definitely repeatable. I've tried the binary download and building from source pgcc, both the same results. I see no evidence either machine is having any other serious hardware or software problems. This problem if it turns out to be a possible compiler bug kinda shakes my confidence in the rest of the kernel code it has compiled. And frankly, there are still some unanswered questions like 1. Why does it work building for the P2 machine, when this module is not being optimized for either? Open to all suggestions... Brian bfoddy AT mn DOT mediaone DOT net