Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

On Fri, Dec 30, 2005 at 09:24:32AM +0100, Arjan van de Ven wrote:
> On Fri, 2005-12-30 at 09:15 +0100, Willy Tarreau wrote:
> >
> >
> > I trust your experience on this, but wasn't the lack of testing
> > primarily due to the use of a "special" version of the compiler ?
> > For instance, if we put a short howto in Documentation/ explaining
> > how to build a kgcc toolchain describing what versions to use, there
> > are chances that most LKML users will use the exact same version.
> > Distro maintainers may want to follow the same version too. Also,
> > the fact that the kernel would be designed to work with *that*
> > compiler will limit the maintenance trouble you certainly have
> > encountered trying to keep the compiler up-to-date with more recent
> > kernel patches and updates.
>
> it's not that easy. Simply put: the gcc people release an update every 6
> months; distros "jump ahead" the bugfixes on that usually. (think of it
> like -stable, where distros would ship patches accepted for -stable but
> before -stable got released). Taking an older compiler from gcc.gnu.org
> doesn't mean it's bug free. It just means you're not getting bugfixes.

OK, but precisely, we don't have any bug free version of gcc anyway. The
kernel has a long history of workaround for gcc bugs. So probably there
will be less work with a -possibly buggy- old gcc version than with a
constantly changing one. For instance, if we stick to 3.4 for 2 years,
we will of course encounter a lot of bugs. But they will be worked around
just like gcc-2.95 bugs have been, and we will be able to keep the same
compiler very long at virtually zero maintenance work.

A few years ago, I had to work on a mainframe system with gcc 1.37.
Yes, 1.37 !!! It was very limited, but I could adapt my code to it
without thinking about what would happen when they update it precisely
because it was not meant to evolve at all. It had been shipped like
this with the OS for 5 years and that was OK. With stable tools like
this, any bug becomes a feature because you don't risk someone fixing
it and breaking your workaround.

While it would be a real problem for user-space tools, I think it
is compatible with kernel needs. The kernel already has strict
requirements to be built and does not need the same level of
portability as pdksh or openssh for instance.

Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • [RFC][PATCH-2.6] Clean up and merge compiler-*.h
    ... the kernel headers in include/linux to include/linux-abi. ... * Common definitions for all gcc versions go here. ... -/* Some compiler specific definitions are overwritten here ...
    (Linux-Kernel)
  • Re: [Bugme-new] [Bug 13012] New: 2.6.28.9 causes init to segfault on Debian etch; 2.6.28.8 OK
    ... before reporting this bug, but this might be the best I can do for the next few ... The system in question is a Debian etch system which has a static /dev (no ... the resulting kernel works again. ... I have not yet had a chance to try vanilla gcc 4.1.2. ...
    (Linux-Kernel)
  • [rfc] built-in native compiler for Linux?
    ... Perhaps we should fork off gcc and ship Linux with its own ... This way we can optimize it for the kernel and not worry ... I didnt suggest forking GCC. ... What i think makes sense is to build a _new_ precompiler / compiler ...
    (Linux-Kernel)
  • Re: [RFC] Stupid tracepoint ideas
    ... gcc forbids jumping outside of inline assembly statements. ... but for some reason no kernel developer I know seems to be ... There are some kernel developers who are also GCC developers - but i ... I think the solution is obvious: the kernel needs its own compiler. ...
    (Linux-Kernel)
  • Re: Use of C99 int types
    ... the compiler. ... > Except the kernel wants to be optimized and work and use what features ... And where exactly are linux and libc when compiling code for an ... Just to make the bloody point GCC is not dependent on Linux in any way ...
    (Linux-Kernel)