Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Jun 2018 06:02:17 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Kurt Lidl <lidl@pix.net>
Cc:        Dimitry Andric <dim@freebsd.org>, src-committers@freebsd.org,  svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r334947 - head/sys/modules
Message-ID:  <20180617044603.I5366@besplex.bde.org>
In-Reply-To: <b87a18ea-8580-7c46-ade0-9beee7528b55@pix.net>
References:  <201806110842.w5B8g4we013345@repo.freebsd.org> <b87a18ea-8580-7c46-ade0-9beee7528b55@pix.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Jun 2018, Kurt Lidl wrote:

> On 6/11/18 4:42 AM, Dimitry Andric wrote:
>> ///
>> Log:
>>    Disable building aesni with base gcc
>>       Because base gcc does not support the required intrinsics, do not
>>    attempt to compile the aesni module with it.
>> ...
>> Modified: head/sys/modules/Makefile
>> ==============================================================================
>> --- head/sys/modules/Makefile	Mon Jun 11 08:11:35 2018	(r334946)
>> +++ head/sys/modules/Makefile	Mon Jun 11 08:42:03 2018	(r334947)
>> @@ -627,7 +627,9 @@ _aac=		aac
>>   _aacraid=	aacraid
>>   _acpi=		acpi
>>   .if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
>> +.if ${COMPILER_TYPE} != "gcc" || ${COMPILER_VERSION} > 40201
>>   _aesni=		aesni
>> +.endif
>>   .endif
>>   _amd_ecc_inject=amd_ecc_inject
>>   _amdsbwd=	amdsbwd

LINT is still broken.  LINT would be even more broken if aesni were removed
from it, since its purpose is to detect uncompilable code.

> I thought that FreeBSD's base gcc (but not a stock 4.2.1 gcc) had support for 
> this.  As documented in UPDATING:
>
> 20130903:
>  AES-NI intrinsic support has been added to gcc.  The AES-NI module
>  has been updated to use this support.  A new gcc is required to build
>  the aesni module on both i386 and amd64.

-maes is accepted by the version of gcc-4.2.1 that I used (buuilt under
-current a year or 2 ago), aesni also hard-codes -msse4 and -mpclmul and
-msha in CFLAGS.  gcc-4.2.1 has no chance of supporting the large changes
needed for at least SSE4 (it does accept -msse3).  aesni wasn't broken to
use -msse4 until 2014/12/12.

Not much else is broken in LINT except this: on i386:
- LINT doesn't even config cleanly, since it duplicates (or tries to vary)
   options in DEFAULTS.  It even duplicates one of its own options by
   placing it in the undocumented section as well as in a documented
   section.  Bitrot in the undocumented section has filled it with many
   documented options.  These errors is not fatal.
- the UKBD_DFLT_KEYMAP option is broken by referencing a file outside of
   the sys tree where it doesn't always exist
- handling of the previous bug is broken.  An empty header file is created
   so the creation error is not detected again.  Compiling ukbd.c fails
   because the empty header doesn't contain the declarations needed.
- a few more files have conversions between pointers and integers of
   different sizes.

On amd64:
- fpu.c fails to compile in all kernels, not just LINT, since it uses
   ifuncs
- efirt.c fails to compile since it dereferences a pointer to an incomplete
   type.  It is "optional efirt", so this doesn't break most kernels.  It
   is not configured by GENERIC either.
- tcp_hpts.c fails to compile because uses a line with a syntax error in
   sys/kern/prefetch.h (an colon to start a clobber list in an asm statement,
   and then no clobber list)).  The same line has about 10 style bugs.
- no files fail to compile due to conversions between pointers and integers
   of different sizes.

Building of modules is completely broken, but I usually turn them off.
I use makeoptious to set CC to gcc-4.2.1, and COMPILER_TYPE to gcc,
and also to put gcc-specific flags in CONF_CFLAGS.  CC is not inherited
in subdirs, but CONF_CFLAGS is, so when the wrong cc is used for modules
it always fails if it uses CFLAGS.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180617044603.I5366>