Why can't lang/gcc4X compilers build kernel modules?

[Dimitry Andric]

On May 10, 2013, at 18:59, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
> It seems, none of the gcc-ports have the FreeBSD-extensions, that are worked into the base cc. This is fine for regular ports, but the consumers of bsd.kmod.mk (such as print/acroreadwrapper or multimedia/cuse4bsd-kmod) all choke. For example:
> gcc46 -O2 -pipe -march=prescott -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common  -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -c linux_adobe.c
> cc1: error: unrecognized command line option '-mno-align-long-strings'
> cc1: error: unrecognized command line option '-fformat-extensions'
> *** Error code 1
> Would it be too much work to extend the port-installed compilers the same way gcc-4.2.1 in the base is extended? May be not for gcc4[89], which are complete rewrites, but for 4.[4-7]? If not too difficult, should it be done?

In my opinion, this is a fruitless direction.  Neither upstream gcc, nor
upstream clang will ever accept an option called "-fformat-extensions",
which enables FreeBSD kernel-specific format extensions (which might
also change in the future, so you do not really gain anything).

I think the best solution is to get rid of all non-standard printf
format specifiers in the kernel, and use custom formatters for our
specialized needs.  For replacing the %b specifier, for example, we
could use NetBSD's snprintb() (see
<http://netbsd.gw.com/cgi-bin/man-cgi?snprintb+3+NetBSD-current>).

Getting rid of non-standard extensions in general is really the way to
go.  This would enable compiling with any standards-compliant compiler,
even commercial ones.


> Once implemented, it would become easier to build the entire kernel using a newer compiler. And dim@ (CC-ed) has already demonstrated non-trivial speed-ups obtained by building the kernel with gcc-4.7 over gcc-4.2:
> http://lists.freebsd.org/pipermail/freebsd-current/2012-November/037842.html
> http://www.andric.com/freebsd/perftest/perftest-kernel-2012-09-25b.txt

Of course recent versions of gcc will be more feature-complete, result
in faster code, etc.  But please be reminded of the GPLv3 licensing
issues with them.  The license is not acceptable for everybody.  (And
yes, I know the license does not apply to the generated code, that is
not the point. :)

-Dimitry