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-all
mailing list