www.delorie.com/archives/browse.cgi   search  
Mail Archives: pgcc/2000/07/20/22:31:09

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 <bfoddy AT mn DOT mediaone DOT net>
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
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019