This is needed for -m32 support which is used in the kernel cloudabi32 module.
Tweak the style to make it easier to understand.
MFC after: 2 weeks
X-MFC-with: r335706
Reported by: Mark Millard
Sponsored by: Dell EMC
Need to handle LLD_BOOTSTRAP separately (for archs like i386).
This would be much better off with an off-by-default option like
SHARED_TOOLCHAIN that universe force-enabled. Then a normal buildworld
would store the toolchain there if enabled and otherwise in WORLDTMP
with only the 1 arch selected.
MFC after: 3 weeks
Sponsored by: Dell EMC
LLVM_TARGET_* will auto be set based on LLVM_TARGET_ALL and MK_CLANG.
If LLVM_TARGET_ALL is disabled, during a cross-build, then SYSTEM_COMPILER
and SYSTEM_LINKER are auto disabled.
This option should be used by users rather than the per-arch LLVM_TARGET
options as it is simpler to maintain for them should the supported
target list change.
MFC after: 2 weeks
Reviewed by: sbruno, dim
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D16020
Allow attaching of multiple geli providers at once if they use same
passphrase and keyfiles.
This is helpful when the providers being attached are not used for boot,
and therefore the existing code to first try the cached password when
tasting the providers during boot does not apply.
Multiple providers with the same passphrase and keyfiles can be attached
at the same time during system start-up by adding the following to
rc.conf:
geli_groups="storage backup"
geli_storage_flags="-k /etc/geli/storage.keys"
geli_storage_devices="ada0 ada1"
geli_backup_flags="-j /etc/geli/backup.passfile -k /etc/geli/backup.keys"
geli_backup_devices="ada2 ada3"
Reviewed by: wblock, delphij, jilles
Approved by: sobomax (src), bcr (doc)
Differential Revision: https://reviews.freebsd.org/D12644
To workaround buggy firmware that sets this flag when there's actually
a VGA present.
Reported and tested by: Yasuhiro KIMURA <yasu@utahime.org>
Sponsored by: Citrix Systems R&D
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D16003
Add documentation and symlinks for OF_getprop_alloc_multi
and OF_getencprop_alloc_multi functions.
Also while here fix copy-pasted .Dt value and add one more
failure condition for OF_getencprop_alloc.
r332341 introduced OF_getencprop_alloc_multi that should be used
instead of OF_getencprop_alloc to get multi-cell properties.
Fix example to reflect this change.
Normally pf rules are expected to do one of two things: pass the traffic or
block it. Blocking can be silent - "drop", or loud - "return", "return-rst",
"return-icmp". Yet there is a 3rd category of traffic passing through pf:
Packets matching a "pass" rule but when applying the rule fails. This happens
when redirection table is empty or when src node or state creation fails. Such
rules always fail silently without notifying the sender.
Allow users to configure this behaviour too, so that pf returns an error packet
in these cases.
PR: 226850
Submitted by: Kajetan Staszkiewicz <vegeta tuxpowered.net>
MFC after: 1 week
Sponsored by: InnoGames GmbH
This makes it possible, through src.conf(5) settings, to select which
LLVM targets you want to build during buildworld. The current list is:
* (WITH|WITHOUT)_LLVM_TARGET_AARCH64
* (WITH|WITHOUT)_LLVM_TARGET_ARM
* (WITH|WITHOUT)_LLVM_TARGET_MIPS
* (WITH|WITHOUT)_LLVM_TARGET_POWERPC
* (WITH|WITHOUT)_LLVM_TARGET_SPARC
* (WITH|WITHOUT)_LLVM_TARGET_X86
To not influence anything right now, all of these are on by default, in
situations where clang is enabled.
Selectively turning a few targets off manually should work. Turning on
only one target should work too, even if that target does not correspond
to the build architecture. (In that case, LLVM_NATIVE_ARCH will not be
defined, and you can only use the resulting clang executable for
cross-compiling.)
I performed a few measurements on one of the FreeBSD.org reference
machines, building clang from scratch, with all targets enabled, and
with only the x86 target enabled. The latter was ~12% faster in real
time (on a 32-core box), and ~14% faster in user time. For a full
buildworld the difference will probably be less pronounced, though.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11077
This works similar to WITH_SYSTEM_COMPILER added in r300354. It only
supports lld via WITH_LLD_BOOTSTRAP.
When both SYSTEM_COMPILER and SYSTEM_LINKER logic passes then libclang
will not build in cross-tools. If either check fails though then
libclang is built.
The .info is reworked to notify when libclang will be built since if
either clang or lld needs to be rebuilt, but not the other, the
notification can lead to confusion on why "clang is building".
-fuse-ld= is not used with this method so some combinations of compiler
and linker are expected to fail.
A new 'make test-system-linker' target is added to see the logic results.
Makefile.inc1:
CROSS_BINUTILS_PREFIX support had to be moved higher up so that XLD
could be set and MK_LLD_BOOTSTRAP disabled before checking SYSTEM_LINKER
logic as done with SYSTEM_COMPILER. This also required moving where
bsd.linker.mk was read since XLD needs to be set before parsing it. This
creates a situation where src.opts.mk can not test LINKER_FEATURES or
add LLD_BOOTSTAP to BROKEN_OPTIONS.
Reviewed by: emaste (earlier version)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15894
Implement a ddb function walking the namecache to do this.
Reviewed by: jhb, mjg
Inspired by: gdb macro from jhb (old version)
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D14898
try to build them if MK_OPENSSL is unset.
Reviewed by: emaste imp kevans
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15211
The nvlist_append_{bool,number,string,nvlist,descriptor}_array() functions
allows to dynamically extend array stored in the nvlist.
Submitted by: Mindaugas Rasiukevicius <rmind@netbsd.org>
All information which are need for those operations is already stored in
the cookie.
We decided not to bump libnv version because this API is not used yet in the
base system.
Reviewed by: pjd
Aligns the build with the FreeBSD traditional approach to not build in
contrib/, and to track inter-dependencies between libraries.
With help from: bdrewery
Reviewed by: bdrewery, hselasky
Sponsored by: Mellanox Technologies
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D15648
objdump is sometimes used in cases where readelf is more appropriate,
but the obsolete GNU objdump we have in the base system will be removed
in the future.
.Xr readelf from elf.5 to improve the odds the more appropriate tool
will be found.
PR: 229046
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Implement MK_NVME now that the expression for where NVMe is
complicated. Default it to "yes" for x86 and powerpc64 and
no everywhere else. Use it in camcontrol to define WITH_NVME
for those platforms where we support nvme.
This should fix the newly introduced nvme files to camcontrol
which were building everywhere.
Pointy Hat To: imp
Sponsored by: Netflix
The handbooks are not installed there anymore. While here, improve the
URLs markup a bit.
Reviewed by: allanjude@
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15793
Most kernel memory that is allocated after boot does not need to be
executable. There are a few exceptions. For example, kernel modules
do need executable memory, but they don't use UMA or malloc(9). The
BPF JIT compiler also needs executable memory and did use malloc(9)
until r317072.
(Note that a side effect of r316767 was that the "small allocation"
path in UMA on amd64 already returned non-executable memory. This
meant that some calls to malloc(9) or the UMA zone(9) allocator could
return executable memory, while others could return non-executable
memory. This change makes the behavior consistent.)
This change makes malloc(9) return non-executable memory unless the new
M_EXEC flag is specified. After this change, the UMA zone(9) allocator
will always return non-executable memory, and a KASSERT will catch
attempts to use the M_EXEC flag to allocate executable memory using
uma_zalloc() or its variants.
Allocations that do need executable memory have various choices. They
may use the M_EXEC flag to malloc(9), or they may use a different VM
interfact to obtain executable pages.
Now that malloc(9) again allows executable allocations, this change also
reverts most of r317072.
PR: 228927
Reviewed by: alc, kib, markj, jhb (previous version)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D15691
