svn commit: r226665 - head/sys/conf

Bruce Evans brde at optusnet.com.au
Mon Oct 24 04:40:09 UTC 2011


On Sun, 23 Oct 2011, Dimitry Andric wrote:

> On 2011-10-23 18:27, Robert Millan wrote:
>> Log:
>>    Conditionalize a pair of FreeBSD GCC extensions so that its CFLAGS are 
>> only
>>    used with FreeBSD GCC.

Bug in non-FreeBSD gcc.

>> Modified: head/sys/conf/kern.mk
>> ==============================================================================
>> --- head/sys/conf/kern.mk	Sun Oct 23 16:04:07 2011	(r226664)
>> +++ head/sys/conf/kern.mk	Sun Oct 23 16:27:03 2011	(r226665)
>> @@ -1,11 +1,21 @@
>>   # $FreeBSD$
>> 
>> +.if ${CC:T:Mclang} != "clang"
>> +FREEBSD_GCC!=	${CC} --version | grep FreeBSD || true
>> +.endif
>> +

Runtime tests like this should never be used in central makefiles since
they are slow.  This one doesn't even work.  Use some user-defined-macro
like NON_FREEBSD_GCC.

>>   #
>>   # Warning flags for compiling the kernel and components of the kernel:
>>   #
>> +.if ${FREEBSD_GCC}
>> +# FreeBSD extensions, not available in upstream GCC
>> +format_extensions=	-fformat-extensions
>> +no_align_long_strings=	-mno-align-long-strings
>> +.endif

How can this help?  Builds should still fail due to -Wformat (-Werror)
errors when the FreeBSD format extensions are used, and kernel code
uses them a lot.  You can turn off -Werror or -Wformat but then the
non-FreeBSD gcc is even more unsuitable for development.

> Note: this breaks builds where CC=clang, with:
>
>>>> Kernel build for GENERIC started on Sun Oct 23 22:01:23 CEST 2011
> ...
> make KERNEL=kernel cleandir
> "/usr/src/sys/conf/kern.mk", line 10: Malformed conditional (${FREEBSD_GCC})
> "/usr/src/sys/conf/kern.mk", line 14: if-less endif
> make: fatal errors encountered -- cannot continue
> ...
>
> Since our base 'clang --version' also has 'FreeBSD' in its output, you
> might want to drop the first .if ${CC:T:Mclang} != "clang" test.  E.g.
> just unconditionally set the FREEBSD_GCC macro (although it's then no
> longer correctly named, but that aside).

clang is broken for -mno-align-long-strings too.  This is worked around
using a static test on ${CC}.

clang also doesn't support -mpreferred-stack-boundary.  This handled
using using a static test on ${MACHINE_CPUARCH}.  This is correct for
clang, since it handles stack alignment better than gcc and uses the
minimal alignment.

clang doesn't properly fail when 1 or both of -mno-align-long-strings
or -mpreferred-stack-boundary.  It prints a diagnostic, but exits
with status 0 even with -Werror, and even if the -mpreferred-stack-
boundary arg is invalid so that it would case a fatal error with gcc.

amd64 never used -preferred-stack-boundary even for gcc.  It is avoided
using the same static test on ${MACHINE_CPUARCH}.  I'm not sure if this
is a bug, of if the ABI requires 16-byte alignment even in the
freestanding case.  Certainly, the hardware only prefers 8-byte alignment
for most args, like it only prefers 4-byte alignment on i386.  Both amd64
and i386 require 16-byte alignment for some SSE args.  This should be
implemented by aligning the stack only if such args exists, like clang
does on i386.

amd64 never used -mno-align-long-strings even for FreeBSD gcc where it is
supported.

Bruce


More information about the svn-src-head mailing list