Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!panix!not-for-mail
From: wpaul@panix.com (Bill Paul)
Newsgroups: comp.os.386bsd.misc
Subject: gcc 2.6.0 on FreeBSD 1.1.5[.1]
Date: 17 Jul 1994 15:02:15 -0400
Organization: The M00se Illuminati (bl00p!)
Lines: 113
Message-ID: <30bv7n$aet@panix3.panix.com>
NNTP-Posting-Host: panix3.panix.com
X-Newsreader: TIN [version 1.2 PL2]
Well, in case anybody's interested, I decided to give the recently
released gcc 2.6.0 a spin on FreeBSD 1.1.5, just for the sheer hell of
it. Here's what happened:
Aside from the fact that it took forever to finish on only 4 megs RAM
(on a 386sx/16 no less -- ack!), the compiler build went off without
a hitch. I only built GNU CC, not C++ or Objective C, since I wanted
to test the bugger before the end of the century. The docs say that a
new version of libg++ is required in order to get g++ to work anyway.
I built the second stage and third stage compilers and did a 'make
compare,' as follows:
% make LANGUAGES=c
% make stage1
% make LANGUAGES=c CC="stage1/xgcc -Bstage1/" CFLAGS="-O"
% make stage2
% make LANGUAGES=c CC="stage2/xgcc -Bstage2/" CFLAGS="-O"
% make compare
% make install LANGUAGES=c CC="stage2/xgcc -Bstage2/" CFLAGS="-O"
There were no errors so I installed the thing and commenced
to playing with it.
I tested it with a few simple programs and it seemed to check out okay.
(Note that I don't know nuthin' about stress testin' no compilers, so
this statement is to be taken with a large grain of sodium chloride. :)
The only odd thing I noticed was the fact that the unstripped executables
it produced were a bit big (a simple 'hello world' ended up being about
22K in size, as opposed to 8K with the 'native' compiler). I think this
is due to the fact that gcc 2.6.0 is using its own static version of libgcc
at this point. (Haven't given thought to how to make a shared version
yet.) Stripping the executables fixes this for now.
Next step was to try to compile the FreeBSD kernel. Here I ran into a
small problem: things went smoothly until gcc fell over while trying to
compile /usr/src/sys/i386/isa/fd.c (newlines inserted for readability):
/usr/local/bin/gcc -c -O -D__FreeBSD__ -W -Wreturn-type -Wcomment -I.
-I../.. -I../../sys -DSKYNET -DI386_CPU -DSYSVSEM -DSHMMAXPGS=64 -DSYSVSHM
-DSYSVMSG -DFIFO -DNCONS=4 -DGATEWAY -DFAT_CURSOR -DUCONSOLE -DXSERVER
-DTCP_COMPAT_42 -DCOMPAT_43 -DPCFS -D NFS -DINET -DKERNEL -Di386 -DNPX
../../i386/isa/fd.c
../../i386/isa/fd.c: In function `fdstate':
../../i386/isa/fd.c:1196: fixed or forbidden register was spilled.
This may be due to a compiler bug or to impossible asm
statements or clauses.
*** Error code 1
Stop.
Line 1196 is the closing brace for the fdstate() function. I saw a bug
report on gnu.gcc.bug from somebody who encountered a similar problem
while trying to build the Linux kernel with gcc 2.6.0. (They had the same
error message flagged on a closing brace in /linux/init/main.c.)
The fdstate() function in fd.c doesn't have any explicit assembler
statements in it (that I could see), but it does make liberal use of
outb(). Snooping around, I discovered the following bit of code in
/usr/src/sys/i386/include/cpufunc.h:
static inline void
outb(u_int port, u_char data)
{
register u_char al asm("ax");
al = data; /* help gcc-1.40's register allocator */
__asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port));
}
I decided to change that to this:
static inline void
outb(u_int port, u_char data)
{
__asm __volatile("outb %0,%%dx" : : "a" (data), "d" (port));
}
This seemed to fix the problem, and I was able to finish the kernel
build without any further incident. I'm running on it now, in fact.
The resulting kernel was about 8K larger than the one built with
gcc 2.4.5:
-r--r--r-- 1 bin bin 650532 Jul 17 02:15 vmunix
-r--r--r-- 1 bin bin 642340 Jul 13 23:22 vmunix.245
(This particular kernel has the full sound driver, PPP, the Berkeley
packet filter and SysV IPC added in, and all the ethernet and SCSI
stuff taken out.)
Now, as to why the compiler barfed on outb(), the comment in the
outb() function seems to suggest that the stuff I yanked out was
essentially a bit of hackery meant to pacify an older version of
gcc. Apparently, said hackery is no longer legal in 2.6.0. The
question, of course, is whether this change was done deliberately or
by mistake, which is something I'll leave to Those Who Know More Than
Me to decide. (My personal and inadequately educated optinion is that
this is in fact a feature and not a bug.) Either way, the error
message is more than a little misleading.
Anyway, just thought I'd share this bit of info with y'all. Turned
out to be one heck of a weekend project, I must say. Man, I *have*
to get a faster computer. :)
-Bill
--
_ /\ _ Join the
/ \_/\_/ \_/\_/ \ .----. M00se Illuminati Bill Paul
\_____/ () \_____/ (bl00p!) Face it: wouldn't <Big City M00se>
/ \ `----' you feel much wpaul@panix.com -or-
/ \__/ \ --' safer? ghod@drycas.club.cc.cmu.edu
/__________\