Re: svn commit: r202628 - in head: . sys/amd64/amd64 sys/i386/i386 sys/i386/xen sys/sys

[ Available lists | Index of svn-src-head | Month of Jan 2010 | Week of 19 Jan 2010 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Dag-Erling Smørgrav <des@des.no>
Date
19 Jan 2010 16:42:55
Subject
Re: svn commit: r202628 - in head: . sys/amd64/amd64 sys/i386/i386 sys/i386/xen sys/sys
Message-ID
863a22dp0x.fsf@ds4.des.no


[ Hide this part ]
Scott Long <scottl@samsco.org> writes:
> Ok, so you've broken a legitimate piece of compatibility. What's the
> gain?

GCC had inline functions long before they were added to the C standard.
Inline functions were introduced in C99 with different semantics (and
believe me, that was not a gratuitous decision). We use C99 semantics
throughout the kernel, except in the pmap code, which Ed just modified,
where we use GCC semantics. This means that in order to compile FreeBSD
with a different compiler, that compiler must not only support both C99
and GCC semantics, but it must also support GCC's syntax - or something
close to it - for specifying, on a per-function basis, which semantics
apply. I say "on a per-function basis" because there are places in the
kernel where pmap headers are included alongside headers that use C99
semantics, so you can't select inline semantics on a per-compilation-
unit basis.

To add insult to injury, GCC's syntax for specifying the precise manner
in which GCC should violate the standard violates the standard...

I haven't checked, but I believe that we can still build 8 / 9 kernels
on 7 as long as we have a cross toolchain available (i.e. make
buildworld, make toolchain or make kernel-toolchain before make
buildkernel), so this really isn't a big issue.

DES
--
Dag-Erling Smrgrav - des@des.no


Elapsed time: 0.084 seconds