aesni on i386 w/gcc breaks 11-STABLE kernel build

[Dimitry Andric]

On 30 May 2018, at 04:29, Dan Allen <danallen46 at gmail.com> wrote:
> 
> I am building FreeBSD 11 stable i386 on an old Pentium 4 machine.  The clang/llvm build is just horrific in length, so I am substituting gcc by the appropriate /etc/src.conf defines such as WITHOUT_CLANG, WITHOUT_CLANG_BOOTSTRAP, WITH_GCC, WITH_GCC_BOOTSTRAP.
> 
> After deleting clang via make delete-old in /usr/src, all of userland builds fine, but the kernel will not build due to the aesni module.

Hmm, I wonder how you managed to build world, as my build ends with the
following errors:

In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:111:1: error: "__fldcw" redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:98:1: error: this is the location of the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:112:1: error: "__fldenv" redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:99:1: error: this is the location of the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:114:1: error: "__fnstcw" redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:105:1: error: this is the location of the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:115:1: error: "__fnstenv" redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:104:1: error: this is the location of the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:116:1: error: "__fnstsw" redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:106:1: error: this is the location of the previous definition
*** [exponential_test.o] Error code 1

make[6]: stopped in /usr/src/lib/msun/tests
1 error

This is on a cleanly installed 11.2-BETA2, with the following in
/etc/src.conf:

MK_CLANG=no
MK_CLANG_BOOTSTRAP=no
MK_CLANG_EXTRAS=no
MK_CLANG_FULL=no
MK_CLANG_IS_CC=no
MK_GCC=yes
MK_GCC_BOOTSTRAP=yes
MK_GNUCXX=yes
MK_LLD=no
MK_LLD_BOOTSTRAP=no
MK_LLD_IS_LD=no
MK_LLDB=no

It looks like the macros in fenv.h and ieeefp.h are clashing, and Ngie
Cooper worked around it in
https://svnweb.freebsd.org/changeset/base/321483, but for some reason
only for clang.

But even after I applied a band-aid for this, it dies on another part:

--- all_subdir_stand ---
cc1: warnings being treated as errors
/usr/src/stand/i386/gptboot/gptboot.c: In function 'main':
/usr/src/stand/i386/gptboot/gptboot.c:258: warning: declaration of 'autoboot' shadows a global declaration
/usr/src/stand/common/bootstrap.h:64: warning: shadowed declaration is here
*** [gptboot.o] Error code 1

make[5]: stopped in /usr/src/stand/i386/gptboot
1 error

Here the warning is right, as 'autoboot' is indeed shadowed, though it
may not be problematic in practice.


> The build break is due to compiling /usr/src/sys/crypto/aesni/aesni_ghash.c, which in turn #includes wmmintrin.h, emmintrin.h, and smmintrin.h which are all clang-specific headers.

In this case, you cannot compile it with gcc-in-base, since it is too
old to have the right intrinsics headers.


> I am rebuilding with MK_CRYPT=no to see if this works around the problem, but it seems like perhaps just this one aesni module should not be built rather than all of CRYPT having to be disabled.

Probably only the module should be disabled, if the version of gcc is
too old.  I have no idea where the needed intrinsics headers were added
upstream.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20180530/94fd232d/attachment.sig>