sys: move SAN and COVERAGE options handling to kern.mk

This allows the flags to be picked up more easily when building external
modules.

Sponsored by: Juniper Networks, Inc.
Reviewed by: markj (ear

sys: move SAN and COVERAGE options handling to kern.mk

This allows the flags to be picked up more easily when building external
modules.

Sponsored by: Juniper Networks, Inc.
Reviewed by: markj (earlier)
Differential Revision: https://reviews.freebsd.org/D45563

show more ...

sys/conf: Introduce NOSAN_CFLAGS and NOSAN_C

To simplify disabling the kernel sanitizers in some files add
NOSAN_CFLAGS and NOSAN_C variables. These are CFLAGS and NORMAL_C with
the sanitizer flags

sys/conf: Introduce NOSAN_CFLAGS and NOSAN_C

To simplify disabling the kernel sanitizers in some files add
NOSAN_CFLAGS and NOSAN_C variables. These are CFLAGS and NORMAL_C with
the sanitizer flags removed.

While here add MSAN_CFLAGS to simplify keeping KMSAN in kern_kcov.c

Reviewed by: khng, brooks, imp, markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45498

show more ...

sanitizers: Avoid building genassym.c and genoffset.c with sanitizers

Some, particularly KASAN, may insert redzones around global symbols,
resulting in incorrect offset definitions because genassym.

sanitizers: Avoid building genassym.c and genoffset.c with sanitizers

Some, particularly KASAN, may insert redzones around global symbols,
resulting in incorrect offset definitions because genassym.sh (ab)uses
symbol sizes to assign semantic meaning.

(Ideally I would be able to define this pattern in one place, but I
haven't found a way to define a GENSYM_CFLAGS that actually works for
all of the consumers (kern.post.mk, kmod.mk, sys/conf/files*).)

MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Juniper Networks, Inc.

show more ...

sys: ${CFLAGS:N-flto} -> ${CFLAGS:N-flto*}

For the same reason as the original https://reviews.freebsd.org/D9659:
-flto=<N>, -flto=full, and -flto=thin also produce the GIMPLE/bitcode
which is not s

sys: ${CFLAGS:N-flto} -> ${CFLAGS:N-flto*}

For the same reason as the original https://reviews.freebsd.org/D9659:
-flto=<N>, -flto=full, and -flto=thin also produce the GIMPLE/bitcode
which is not supported by genassym, so filter those out as well.

Signed-off-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/898

show more ...

Set installed kernel and driver files access modes using KMODMODE var

Reviewed by: emaste, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.o

Set installed kernel and driver files access modes using KMODMODE var

Reviewed by: emaste, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D42768

show more ...

sys/conf: Move adding kernel.bin earlier

When building with kernel.bin enabled we need to set KERNEL_EXTRA and
KERNEL_EXTRA_INSTALL before they are used otherwise kernel.bin isn't
built.

Reviewed b

sys/conf: Move adding kernel.bin earlier

When building with kernel.bin enabled we need to set KERNEL_EXTRA and
KERNEL_EXTRA_INSTALL before they are used otherwise kernel.bin isn't
built.

Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42531

show more ...

arm: Introduce MK_KERNEL_BIN to control generation of kernel.bin

It's sometimes desirable to generate kernel.bin and install it. While
the mainstream has moved on to UEFI booting on arm, some specia

arm: Introduce MK_KERNEL_BIN to control generation of kernel.bin

It's sometimes desirable to generate kernel.bin and install it. While
the mainstream has moved on to UEFI booting on arm, some specialized
gear can't support it. For that gear, we unconditionally generate
kernel.bin. Add a knob so that WITH_KERNEL_BIN or WITHOUT_KERNEL_BIN
control its generation and installation. config files should add
'makeoptions WITH_KERNEL_BIN=t' to enable it. Since its use is
specialized, it is off by default now since the arm world has largely
moved on to UEFI.

It only affects arm and arm64 (since those are the only two that support
it).

Sponsored by: Netflix
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D39013

show more ...

Add the BBR and RACK stacks to the LINT kernel.

While here, drop the EXTRA_TCP_STACKS option, which serves no purpose and
should never have been added. Instead, build bbr and rack as long as
either

Add the BBR and RACK stacks to the LINT kernel.

While here, drop the EXTRA_TCP_STACKS option, which serves no purpose and
should never have been added. Instead, build bbr and rack as long as
either or both of INET and INET6 is enabled. There is no risk to anyone
who doesn't load one or both and then twiddle the relevant sysctls.

Differential Revision: https://reviews.freebsd.org/D42088

show more ...

sys: Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Pre-quote macros passed to .incbin to avoid unwanted substitution

Currently for the MFS, firmware and VDSO template assembly files we pass
the path to include with .incbin unquoted and use __XSTRING

Pre-quote macros passed to .incbin to avoid unwanted substitution

Currently for the MFS, firmware and VDSO template assembly files we pass
the path to include with .incbin unquoted and use __XSTRING within the
assembly file to stringify it. However, __XSTRING doesn't just perform a
single level of expansion, it performs the normal full expansion of the
macro, and so if the path itself happens to tokenise to something that
includes a defined macro in it that will itself be substituted. For
example, with #define MACRO 1, a path like /path/containing/MACRO/in/it
will expand to /path/containing/1/in/it and then, when stringified, end
up as "/path/containing/1/in/it", not the intended string. Normally,
macros have names that start or end witih underscores and are unlikely
to appear in a tokenised path (even if technically they could), but now
that we've switched to GNU C as of commit ec41a96daaa6 ("sys: Switch the
kernel's C standard from C99 to GNU99.") there are a few new macros
defined which don't start or end with underscores: unix, which is always
defined to 1, and i386, which is defined to 1 on i386. The former
probably doesn't appear in user paths in practice, but the latter has
been seen to and is likely quite common in the wild.

Fix this by defining the macro pre-quoted instead of using __XSTRING.
Note that technically we don't need to do this for vdso_wrap.S today as
all the paths passed to it are safe file names with no user-controlled
prefix but we should do it anyway for consistency and robustness against
future changes.

This allows make tinderbox to pass when built with source and object
directories inside ~/path-with-unix, which would otherwise expand to
~/path-with-1 and break.

PR: 272744
Fixes: ec41a96daaa6 ("sys: Switch the kernel's C standard from C99 to GNU99.")

show more ...

kern.post.mk allow NEWVERS_{ENV,ARGS}

Allow makefiles better control of newvers.sh env and args.
Also allow variable overrides on command line.

Reviewed by: imp, stevek
Sponsored by: Juniper Networ

kern.post.mk allow NEWVERS_{ENV,ARGS}

Allow makefiles better control of newvers.sh env and args.
Also allow variable overrides on command line.

Reviewed by: imp, stevek
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D41012

show more ...

kern.post.mk: fix PORTSDIR handling

Using subshell's PORTSDIR variable (via $${PORTSDIR}}) seems to be
only working if PORTSDIR is specified directly on the make command
line.

Use ${PORTDIR} here i

kern.post.mk: fix PORTSDIR handling

Using subshell's PORTSDIR variable (via $${PORTSDIR}}) seems to be
only working if PORTSDIR is specified directly on the make command
line.

Use ${PORTDIR} here instead so that setting the variable in
/etc/{make,src,src-env}.conf would work (also works for variable
being set on command line or in the environment).

PR: 268299
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D37868

show more ...

kern.post.mk we need .MAKE.DEPENDFILE for DIRDEPS_BUILD

When MK_DIRDEPS_BUILD is yes, we need .MAKE.DEPENDFILE left
alone

Reviewed by: stevek

sys/conf: Remove an unneeded flag variable

After commit fac6dee9eb58 ("Remove tests for obsolete compilers in the
build system"), we always set -fdebug-prefix-map, so there's no point in
defining an

sys/conf: Remove an unneeded flag variable

After commit fac6dee9eb58 ("Remove tests for obsolete compilers in the
build system"), we always set -fdebug-prefix-map, so there's no point in
defining and testing _MAP_DEBUG_PREFIX. No functional change intended.

MFC after: 1 week
Sponsored by: The FreeBSD Foundation

show more ...

amd64: symlink i386 includes into build dir

By creating an i386 symlink, this allows code compiled with -m32 to
build (32-bit vdso and linux bits) when -m32 support requires files
in the i386 hierar

amd64: symlink i386 includes into build dir

By creating an i386 symlink, this allows code compiled with -m32 to
build (32-bit vdso and linux bits) when -m32 support requires files
in the i386 hierarchy.

Reviewed by: jhb, imp

show more ...

Don't delete hack.c - causes perpetual 'out of date' kernel

Deleting hack.c cause the kernel to always be out of date:

$ make kernel
make: /usr/src/sys/amd64/compile/GENERIC/.depend.hack.pico

Don't delete hack.c - causes perpetual 'out of date' kernel

Deleting hack.c cause the kernel to always be out of date:

$ make kernel
make: /usr/src/sys/amd64/compile/GENERIC/.depend.hack.pico, 1:
ignoring stale .depend for hack.c
:> hack.c
cc -shared -O2 -pipe ... -nostdlib hack.c -o hack.pico
rm -f hack.c
MAKE="make" sh ../../../conf/newvers.sh "-R" GENERIC
cc -c -O2 -pipe ... -std=iso9899:1999 -Werror vers.c
ctfconvert -L VERSION -g vers.o
linking kernel.full

Keeping hack.c in the compile directory causes no harm,
so there's no reason to delete it.

Also rename the file to "force-dyamic-hack.c" so it is
clear what the hack is aboug.

Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D34281

show more ...

amd64: Only build aout.ko when COMPAT_FREEBSD32 is enabled

a.out.ko is useless without COMPAT_FREEBSD32, and since vdso support was
added, it requires a header built during depend phase, from the CO

amd64: Only build aout.ko when COMPAT_FREEBSD32 is enabled

a.out.ko is useless without COMPAT_FREEBSD32, and since vdso support was
added, it requires a header built during depend phase, from the COMPAT
option.

Reported by: glebius
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D33311

show more ...

Fix the KCSAN_ENABLED check when building modules

The KCSAN_ENABLED variable is non-empty when the kernel is being built
with KCSAN. This allows us to disable modules that are known to be
broken.

T

Fix the KCSAN_ENABLED check when building modules

The KCSAN_ENABLED variable is non-empty when the kernel is being built
with KCSAN. This allows us to disable modules that are known to be
broken.

There was a bug where we would check if it was defined. As this is
always the case the KCSAN_ENABLED variable would be set when building
modules so we would never build such a module. Fix this by checking
if the value is empty before passing it on to the module stage.

This doesn't affect how modules are built as the CFLAGS passed to
modules has the correct check.

Reported by: rstone
Sponsored by: Innovate UK

show more ...

x86: remove gcov kernel support

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D29529

Use a template assembly file to generate the embedded MFS.

This uses the .incbin directive to pull in the MFS image contents.
Using assembly directly ensures that symbols can be defined with the
nam

Use a template assembly file to generate the embedded MFS.

This uses the .incbin directive to pull in the MFS image contents.
Using assembly directly ensures that symbols can be defined with the
name and properties (such as .size) desired without having to rename
symbols, etc. via a second objcopy invocation. Since it is compiled
by the C compiler driver, it also avoids the need for all of the
EMBEDFS* make variables.

Suggested by: jrtc27
Reviewed by: kib, markj
Obtained from: CheriBSD
MFC after: 2 weeks
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D26781

show more ...

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Pass -fuse-ld=/path/to/ld if ${LD} != "ld"

This is needed so that setting LD/XLD is not ignored when linking with $CC
instead of directly using $LD. Currently only clang accepts an absolute
path for

Pass -fuse-ld=/path/to/ld if ${LD} != "ld"

This is needed so that setting LD/XLD is not ignored when linking with $CC
instead of directly using $LD. Currently only clang accepts an absolute
path for -fuse-ld= (Clang 12+ will add a new --ld-path flag), so we now
warn when building with GCC and $LD != "ld" since that might result in the
wrong linker being used.

We have been setting XLD=/path/to/cheri/ld.lld in CheriBSD for a long time and
used a similar version of this patch to avoid linking with /usr/bin/ld.
This change is also required when building FreeBSD on an Ubuntu with Clang:
In that case we set XCC=/usr/lib/llvm-10/bin/clang and since
/usr/lib/llvm-10/bin/ does not contain a "ld" binary the build fails with
`clang: error: unable to execute command: Executable "ld" doesn't exist!`
unless we pass -fuse-ld=/usr/lib/llvm-10/bin/ld.lld.

This change passes -fuse-ld instead of copying ${XLD} to WOLRDTMP/bin/ld
since then we would have to ensure that this file does not exist while
building the bootstrap tools. The cross-linker might not be compatible with
the host linker (e.g. when building on macos: host-linker= Mach-O /usr/bin/ld,
cross-linker=LLVM ld.lld).

Reviewed By: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D26055

show more ...

Add necessary Makefile.inc1 infrastructure for building on non-FreeBSD

The most awkward bit in this patch is the bootstrapping of m4:
We can't simply use the host version of m4 since that is not com

Add necessary Makefile.inc1 infrastructure for building on non-FreeBSD

The most awkward bit in this patch is the bootstrapping of m4:
We can't simply use the host version of m4 since that is not compatible
with the flags passed by lex (at least on macOS, possibly also on Linux).
Therefore we need to bootstrap m4, but lex needs m4 to build and m4 also
depends on lex (which needs m4 to generate any files). To work around this
cyclic dependency we can build a bootstrap version of m4 (with pre-generated
files) then use that to build the real m4.

This patch also changes the xz/unxz/dd tools to always use the host version
since the version in the source tree cannot easily be bootstrapped on macOS
or Linux.

Reviewed By: brooks, imp (earlier version)
Differential Revision: https://reviews.freebsd.org/D25992

show more ...

Remove tests for obsolete compilers in the build system

Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
f

Remove tests for obsolete compilers in the build system

Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.

Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802

show more ...

Allow the kernel to build with a compiler that sets -fno-common.

The mechanism that generates assym.inc and offset.inc depends on the
symbols in question being common. For now, simply force the obje

Allow the kernel to build with a compiler that sets -fno-common.

The mechanism that generates assym.inc and offset.inc depends on the
symbols in question being common. For now, simply force the object files
to be created with -fcommon.

-fno-common will be the default in GCC10/LLVM11.

Submitted by: arichardson
Reviewed by: kevans
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24322

show more ...