Re: Recommended compiler version

Re: Recommended compiler version

[Dan Kegel]

John B. wrote:
> Quote from Adrian Bunk <bunk@fs.tum.de>:
>> Whether support for gcc 2.95 should be dropped is a discussion for 2.7.
> 
> Is there any single 3.x.x version of GCC that's actively in use by a large
> number of core developers?  How do we make a sensible recommendation if not?

As an aside, it seems like gcc-3.3.3 is pretty good.
There are some known problems with it, but the number is small.
I haven't tried gcc-3.4.0 much yet, but I have seen a few kernel patches
to fix issues 3.4.0 found in the kernel source.

I agree 2.6 should continue to support and compile correctly under gcc-2.95.3,
even if that means working around compiler bugs.  By the time linux-2.7
rolls around, I suspect nobody will mind if we drop 2.95.3 in favor
of 3.4.x.  It'll be interesting to see if newer gccs optimize the kernel better...
- Dan


-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

Re: Recommended compiler version

[Dan Kegel]

Karim Yaghmour wrote:
> RANT: It's really about time that someone within the GNU project took it
> upon herself to actually get the GNU toolchain to build for cross-dev
> without having to require walking-on-water talents.

Quite.  I'm heading up to the gcc summit next week to make that point
(see also http://gcc.gnu.org/ml/gcc/2004-05/msg01417.html,
which rumors that Paolo Bonzini and Nathanael Nerode are
working on detangling gcc bootstrap).

And I've been busting my ass for the last year maintaining the 'crosstool'
script so people without walking-on-water talents can build
the GNU toolchain for cross-development.  (But before Karim objects
to the concept of a canned build script, I hasten to add that
I fully agree with him that the gnu toolchain build process shouldn't
need such an ugly and fragile wrapper script around it.)

> BTW, the 2.6.6 kernel wouldn't build without the following
> modifications to the main makefile:
> AS              = $(CROSS_COMPILE)as -maltivec
> CFLAGS_KERNEL   = -maltivec
> AFLAGS_KERNEL   = -maltivec
> For some reason 3.4.0 forgets to tell AS that this CPU may have
> Altivec instructions -- there are some postings about this if
> you google around.

I think the issue is that binutils-2.15 started checking its
input more strictly, in a way that broke several apps.  Binutils
cvs has the following patch which is said to relex the check:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/ppc-opc.c.diff?r1=1.70&r2=1.71&cvsroot=src
That patch'll be in the next crosstool, of course.

Thanks for posting about your experiences with gcc-3.4.0
and the link to http://www.ppckernel.org, which I wasn't aware of...
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

Re: Recommended compiler version

[Karim Yaghmour]

Dan Kegel wrote:
> As an aside, it seems like gcc-3.3.3 is pretty good.
> There are some known problems with it, but the number is small.
> I haven't tried gcc-3.4.0 much yet, but I have seen a few kernel patches
> to fix issues 3.4.0 found in the kernel source.

I thought I'd drop in here while there's mention of the kernel and 3.4.0
to describe some recent experiences I've been having on that topic.

Here's some detilas of what I've been trying to get to work:
- hardware: Motorola MCP750 - Mesquite / PowerPC 750
- kernel: 2.4.18 patched with motorola patches for MCP750
- binutils: 2.15
- gcc: 3.4.0
- glibc: 2.3.2

First off, I was able to get the toolchain to build. Needed a few hacks,
but nothing really major.
RANT: It's really about time that someone within the GNU project took it
upon herself to actually get the GNU toolchain to build for cross-dev
without having to require walking-on-water talents. Anyhow ...

I built the kernel with the toolchain, and here's what I got when trying
to launch it from ppc-bug:
---------------------------------------------------------------
PPC1-Bug>nbo 0 0,,, zImage.prep
Network Booting from: DEC21140, Controller 0, Device 0
Device Name: /pci@80000000/pci1011,9@e,0:0,0
Loading: zImage.prep

Client IP Address      = 192.168.12.3
Server IP Address      = 192.168.12.8
Gateway IP Address     = 0.0.0.0
Subnet IP Address Mask = 255.255.255.0
Boot File Name         = zImage.prep
Argument File Name     =

Network Boot File load in progress... To abort hit <BREAK>

Bytes Received =&1018969, Bytes Loaded =&1018969
Bytes/Second   =&1018969, Elapsed Time =1 Second(s)

Residual-Data Located at: $07E88000
loaded at:     00005400 00019234
relocated to:  01000000 01013E34
board data at: 07E88000 07E8EA0C
relocated to:  0100A14C 01010B58
zimage at:     0000F400 000FBC17
relocated to:  01014000 01100817
avail ram:     00400000 00800000

Linux/PPC load: console=ttyS0,9600
cmd_line located > 16M
hold_residual located > 16M
Uncompressing Linux...done.
Now booting the kernel
vector: 300 at pc = 900108b4, lr = 901b847c
msr = 1032, sp = 9019dc80 [9019dbd0]
dar = 0, dsisr = 40000000
current = 9019bcd0, pid = 0, comm = swapper
mon>
---------------------------------------------------------------

[To even get the 2.4.18 kernel to build, I had to modify a few
syscall clobber statements which the recent toolchain didn't like
much. Peaked into 2.4.26's include/asm-ppc/unistd.h for some
inspiration ;)]

To make a very long story short, I was able to actually get this
kernel to start only if I commented out parse_options() and
do_initcalls() in init/main.c. No need to say how ugly this is.
Somehow, if I set cmd_line[0] = '\0' it actually went through
parse options without any problem, but still died in do_initcalls.
Yet, if I looped around and printed out the content of the command
line, it was all OK:
	{
	  int i;
	for (i = 0; i < 256; i++)
	  if (command_line[i] != '\0')
	    printk("Command line entry %d is %c \n", i, command_line[i]);
	  else
	    printk("Command line entry %d is NULL \n");
	}

Feeling that this might be a problem with the 2.4.18 kernel I
was using, I tried a variety of different kernels without the
mot patch: 2.4.25-debian, 2.4.26-vanilla, 2.4.25-benh1, 2.6.6,
etc. Nothing worked. At best, I got to the same spot as earlier.

[ BTW, the 2.6.6 kernel wouldn't build without the following
modifications to the main makefile:
AS              = $(CROSS_COMPILE)as -maltivec
CFLAGS_KERNEL   = -maltivec
AFLAGS_KERNEL   = -maltivec
For some reason 3.4.0 forgets to tell AS that this CPU may have
Altivec instructions -- there are some postings about this if
you google around.]

Finally, despite my reservations about what such a thing would
really change, I decided to try gcc 3.3.2 and gcc 3.2.3.
Surprisingly, this actually worked. The patched 2.4.18 above
booted without any problem whatsoever. I tried a couple of other
kernels as well, to see if they too would work. I noticed that
some that actually failed as above (causing a fault very early
at boot time), now didn't fail with 3.3.2, but printed nothing
to the terminal and the system would eventually reboot -- as if
console=ttyS0,9600 had no effect and the kernel panicked as
expected because of the missing rootfs.

But I wanted to at least have another kernel than the mot 2.4.18
with gcc 3.3.2 working, so I went back to the kernel dated
2004/05/22 downloaded from http://www.ppckernel.org/kernel.php?id=26
-- it's actually a modified 2.4.26 -- and hacked the Makefile and
misc.c files in arch/ppc/boot/prep directory to get it to build.
Once I did this, I was actually able to get this one to build and
boot successfully on the board with both gcc 3.3.2 and gcc 3.4.0.
So there's at least one kernel I was able to get working with
3.4.0.

What's most frustrating is that I came away with not much more
understanding as to why the same parse_options() and
do_initcalls() would build without a warning on gcc 3.4.0 but
would cause a fault at runtime, while building and running
flawlessly with gcc 3.3.2 and gcc 3.2.3 ...

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

Re: Recommended compiler version

[Karim Yaghmour]

Karim Yaghmour wrote:
...
> kernels as well, to see if they too would work. I noticed that
> some that actually failed as above (causing a fault very early
> at boot time), now didn't fail with 3.3.2, but printed nothing
> to the terminal and the system would eventually reboot -- as if
> console=ttyS0,9600 had no effect and the kernel panicked as
> expected because of the missing rootfs.

This just above is actually due pilot error. I had been trying so
many different kernels that I had forgotten to check whether
console on serial was enabled ... No wonder nothing was displayed.

To recap, I've also got the 2.4.25-ben1 and 2.6.6 working with
gcc 3.3.2. 2.4.25-ben1 still has the same problem as described
earlier with gcc 3.4.0, but 2.6.6 works fine with gcc 3.4.0.

I'm probably going to stick to 3.3.2, though, as I have no
intention of chasing gcc 3.4.0's breaking of some user-space
stuff.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

Re: Recommended compiler version

[Karim Yaghmour]

Dan Kegel wrote:
> Quite.  I'm heading up to the gcc summit next week to make that point
> (see also http://gcc.gnu.org/ml/gcc/2004-05/msg01417.html,
> which rumors that Paolo Bonzini and Nathanael Nerode are
> working on detangling gcc bootstrap).

You have my full support.

> the GNU toolchain for cross-development.  (But before Karim objects
> to the concept of a canned build script, I hasten to add that
> I fully agree with him that the gnu toolchain build process shouldn't
> need such an ugly and fragile wrapper script around it.)

:)

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

Re: Recommended compiler version

[John Bradford]

Quote from Dan Kegel <dank@kegel.com>:
> I agree 2.6 should continue to support and compile correctly under gcc-2.95.3,
> even if that means working around compiler bugs.  By the time linux-2.7
> rolls around, I suspect nobody will mind if we drop 2.95.3 in favor
> of 3.4.x.

Especially as newer versions of glibc won't compile with 2.95.3 anymore - so
if you're building a system completely from source, a 3.x.x version of GCC
is more or less a necessity anyway.

John.

Re: Recommended compiler version

[George Georgalis]

On Sat, May 29, 2004 at 03:57:55PM +0100, John Bradford wrote:
>Quote from Adrian Bunk <bunk@fs.tum.de>:
>> Whether support for gcc 2.95 should be dropped is a discussion for 2.7.
>
>Is there any single 3.x.x version of GCC that's actively in use by a large
>number of core developers?  How do we make a sensible recommendation if not?

I've used gcc-3.3.2, since about when it came out. It's been reliable
for me so I haven't noticed/tried newer versions. A few times I had
problems, with xfree or mplayer and reverted to my distro version:
gcc version 2.95.4 20011002 (Debian prerelease)

if a standard, by someone more experienced with c than myself, where
used that indicated preferred, known.works, known.broken versions of
gcc, then developers could maintain the information, for their code,
in a way that would make it easy to make global assertions on what gcc
version is preferred, works or broken. Plus, make errors that say "this
doesn't work with that gcc version" could save a lot of headaches.

// George


-- 
George Georgalis, Architect and administrator, Linux services. IXOYE
http://galis.org/george/  cell:646-331-2027  mailto:george@galis.org
Key fingerprint = 5415 2738 61CF 6AE1 E9A7  9EF0 0186 503B 9831 1631

Re: Recommended compiler version

[Francois Romieu]

John Bradford <john@grabjohn.com> :
[...]
> The _code_ is broken if it doesn't compile with the recommended compiler, not
> the compiler itself.

Second time I read this statement. Discussion is over.

--
Ueimor

Re: Recommended compiler version

[John Bradford]

Quote from Adrian Bunk <bunk@fs.tum.de>:
> Whether support for gcc 2.95 should be dropped is a discussion for 2.7.

Is there any single 3.x.x version of GCC that's actively in use by a large
number of core developers?  How do we make a sensible recommendation if not?

John.

Re: Recommended compiler version

[John Bradford]

Quote from Francois Romieu <romieu@fr.zoreil.com>:
> John Bradford <john@grabjohn.com> :
> [...]
> > In my opinion, code that doesn't compile with 2.95.3 is broken - 2.95.3 is
> 
> If you are asking for technical details, please read the thread ending
> at: http://oss.sgi.com/projects/netdev/archive/2004-05/msg00440.html
> 
> [...]
> > Basically, 2.95.3 is something of a point of reference, so it only makes
> > sense to throw it out once we have a new point of reference.
> 
> It makes no sense to religiously recommended 2.95.3 if it is known broken.

The _code_ is broken if it doesn't compile with the recommended compiler, not
the compiler itself.

> If nobody comes with a better approach, I'll simply submit a patch to
> remove the 2.95.3 recommendation (+ #error for the driver as suggested by ak).

Please leave the recommendation unless it's being replaced by a new one.

John.

Re: Recommended compiler version

[Adrian Bunk]

On Sat, May 29, 2004 at 04:12:47PM +0200, Francois Romieu wrote:
>...
> It makes no sense to religiously recommended 2.95.3 if it is known broken.

In my experience, 2.95.3 isn't more broken than the average 3.3 
compiler.

> If nobody comes with a better approach, I'll simply submit a patch to
> remove the 2.95.3 recommendation (+ #error for the driver as suggested by ak).

The common solution in the kernel for such issues is to change the code 
to compile correctly with all supported compilers.

This might not be a perfect solution, but otherwise different drivers 
might require different compiler versions resulting in a chaos.

Whether support for gcc 2.95 should be dropped is a discussion for 2.7.

> Ueimor

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Recommended compiler version

[Francois Romieu]

John Bradford <john@grabjohn.com> :
[...]
> In my opinion, code that doesn't compile with 2.95.3 is broken - 2.95.3 is

If you are asking for technical details, please read the thread ending
at: http://oss.sgi.com/projects/netdev/archive/2004-05/msg00440.html

[...]
> Basically, 2.95.3 is something of a point of reference, so it only makes
> sense to throw it out once we have a new point of reference.

It makes no sense to religiously recommended 2.95.3 if it is known broken.

If nobody comes with a better approach, I'll simply submit a patch to
remove the 2.95.3 recommendation (+ #error for the driver as suggested by ak).

--
Ueimor

Re: Recommended compiler version

[John Bradford]

Quote from Francois Romieu <romieu@fr.zoreil.com>:
> Francois Romieu <romieu@fr.zoreil.com> :
> [...]
> 
> I forgot to mention: 2.95.3 does not compile correctly the 2.6.6 r8169
> driver.
> 
> The archive does not make clear what should be used. The whole 2.95.[234]
> family seems flaky. :o/

In my opinion, code that doesn't compile with 2.95.3 is broken - 2.95.3 is
still the recommended compiler, and although various developers have been
using 3.x.x versions for a long time, I haven't been aware of any efforts
to test a specific 3.x.x version of GCC over a wide range of kernels.

Basically, 2.95.3 is something of a point of reference, so it only makes
sense to throw it out once we have a new point of reference.

John.

Re: Recommended compiler version

[Andi Kleen]

Francois Romieu <romieu@fr.zoreil.com> writes:

> The linux kernel README and Documentation/CHANGES suggests to use
> gcc 2.95.3. These files have not been updated for ages. Is there
> a rough consensus regarding the required versions of the different
> tools in the buildchain or should one simply submit a patch to remove
> the offending files ?

I would suggest to just remove them. We're past the state when each new
compiler version broke the kernel. Originally that was a lot due 
to buggy inline assembly etc., but that should be all fleshed out now.

> I forgot to mention: 2.95.3 does not compile correctly the 2.6.6 r8169
> driver.

Make it an #error then. Better a compile time error than a mysterious
malfunction.

-Andi

Re: Recommended compiler version

[Francois Romieu]

Francois Romieu <romieu@fr.zoreil.com> :
[...]

I forgot to mention: 2.95.3 does not compile correctly the 2.6.6 r8169
driver.

The archive does not make clear what should be used. The whole 2.95.[234]
family seems flaky. :o/

--
Ueimor

Recommended compiler version

[Francois Romieu]

The linux kernel README and Documentation/CHANGES suggests to use
gcc 2.95.3. These files have not been updated for ages. Is there
a rough consensus regarding the required versions of the different
tools in the buildchain or should one simply submit a patch to remove
the offending files ?

--
Ueimor