More MACHINE_CPUARCH/MACHINE_ARCH cases enable these options than
disable them, and several of them have work in progress to switch over.
Thus, invert the sense of the test and list cases not using LLD as the
exceptions.
There were a few special cases for arm v5, such as disabling LLDB due to
the lack of 64-bit atomic operations. Now that arm has been retired (as
of r356263) we can simplify the options logic somewhat.
We use the BSDL devicetree compiler as long as we have a C++11 compiler.
dtc is not needed as a build tool on the platforms that are still using
GCC 4.2.1 (and it is being disabled very soon, anyhow).
Discussed with: imp, kevans
PowerPC switched to LLVM_LIBUNWIND along with the switch to Clang/LLVM
in r356111. This leaves only 32-bit Arm and sparc64 not using LLVM's
unwinder, so switch the sense to opt-out.
I elected to list the individual arm MACHINE_ARCHs so future changes
are more clear if LLVM_LIBUNWIND is enabled for one or two but not all
32-bit Arm targets (see PR 233664).
After PowerPC switched in r356111, the list of targets using LLVM as the
default toolchain is much longer than those not using it. Switch the
sense of the test to exclude those not using LLVM.
Targets not using LLVM is currently mips, riscv5, and sparc64; work is
in progress to migrate the first two to LLVM.
This enables LLVM as the default compiler for powerpc, powerpc64, and
powerpcspe, as well as LLD as the default linker for powerpc64.
LLD is not yet ready for prime time for powerpc and powerpcspe, but work is
continuing on it.
Submitted by: alfredo.junior_eldorado.org.br
Relnotes: YES
Differential Revision: https://reviews.freebsd.org/D20378
Summary:
This patch is to support ongoing work for replacing "GCC/BFD" by "CLANG/LLD" on
target PowerPC64 [1], by proposing a way to specify and/or locate a secondary
ld.bfd linker.
This is necessary as LLD currently doesn't support PowerPC 32 bits, so we keep
using BFD for the 32 bit stuff on PowePC64(LIB32 compatibility and
STAND/slof/loader.)
- creates LD_BFD variable pointing to ld.bfd
- use LD_BFD as linker for LIB32/compat
- Default behavior for other platforms aren't changed.
[1] https://wiki.freebsd.org/powerpc/llvm-elfv2
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20261
Disable the warning for WARNS <= 3. This is lame, but it's what we
already do for the clang build.
Reviewed by: dim
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22889
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
libmagic only depend on mkmagic if not DIRDEPS_BUILD
libpmc fix -I for libpmcstat
local.dirdeps.mk be even more careful about adding gnu/lib/csu to DIRDEPS
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D22872
The env space consumed by exporting all libc's .meta files
left little room for command line,
so unexport when done.
Update dirdeps.mk to latest and add
dirdeps-targets.mk to simplify/update targets/Makefile
Makefile changes to go with Makefile.depend changes in D22494
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22495
This decouples MK_LLVM_TARGET_ALL from MK_CLANG. It is fine if
LLVM_TARGET_* are set even if MK_CLANG is disabled. It never
made sense to depend MK_LLVM_TARGET_* to MK_CLANG (which I did
in r335706).
PR: 240507
Reported by: kevans, swills
MFC after: 2 weeks
When the linker doesn't have this feature, add -mno-relax to CFLAGS
on RISC-V.
Define the feature for ld.bfd, but not lld. If lld gains relaxation
support in a newer version, we can enable it for those versions of lld
in bsd.linker.mk.
Reviewed by: mhorne
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22659
r341812 enabled only arm target support in LLVM on arm and armv6,
because ld.bfd 2.17.50 lacked support for range extensions required for
linking such large binaries/libraries. r341812 indicated that the
workaround should be removed once the userland can be linked by lld.
r354289 switched armv6 to use lld by default, so remove the workaround
on armv6. The workaround remains in place for arm (v5), and will
presumably be removed when arm is retired.
Sponsored by: The FreeBSD Foundation
This Makefile sets KERN_OPTS. This permits kernel module Makefiles to
use KERN_OPTS to control the value of variables such as SRCS that are
used by bsd.kmod.mk for KERN_OPTS values that honor WITH/WITHOUT
options for standalone builds.
Mount the UEFI ESP on /boot/efi. No current system uses this by default, but
there are many ad-hoc schemes that do this in /efi or /esp or /uefi and adding a
new directory at the top-level would have a much higher likelihood of
collision. Document this in /etc/mtree/BSD.root.mtree and create EFIDIR and
related variables in bsd.own.mk.
Differential Revision: https://reviews.freebsd.org/D21344
Support for NO_CTF, NO_DEBUG_FILES, NO_INSTALLLIB, NO_MAN, NO_PROFILE,
and NO_WARNS as deprecated in 2014 with a warning added for each one
found. Turn these into error in preperation for removal of compatability
support before FreeBSD 13.
Reviewed by: imp
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22448
As of FreeBSD 10.1 the autofs(5) is available for automounting, and the
amd man page has indicated that the in-tree copy of amd is obsolete.
Disable it by default for now, with the expectation that it will be
removed before FreeBSD 13.0.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D22460
FreeBSDlua ("flua") is a FreeBSD-private lua, flavored with whatever
extensions we need for base system operations. We currently support a subset
of lfs and lposix that are used in the rewrite of makesyscall.sh into lua,
added in r354786.
flua is intentionally written such that one can install standard lua and
some set of lua modules from ports and achieve the same effect.
linit_flua is a copy of linit.c from contrib/lua with lfs and lposix added
in. This is similar to what we do in stand/. linit.c has been renamed to
make it clear that this has flua-specific bits.
luaconf has been slightly obfuscated to make extensions more difficult. Part
of the problem is that flua is already hard enough to use as a bootstrap
tool because it's not in PATH- attempting to do extension loading would
require a special bootstrap version of flua with paths changed to protect
the innocent.
src.lua.mk has been added to make it easy for in-tree stuff to find flua,
whether it's bootstrap-flua or relying on PATH frobbing by Makefile.inc1.
Reviewed by: brooks, emaste (both earlier version), imp
Differential Revision: https://reviews.freebsd.org/D21893
In order to allow software with multiple (different) options
for lex and yacc add extra per-file options to the calls.
This is especially useful when one .l file needs -Pprefix.
Reviewed by: imp
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D22337
We need to ensure that installdirs-FOO runs before installfiles-FOO since
otherwise the directory may not exist when we attempt to install the target.
This was randomly causing failures in our Jenkins instance when installing
drti.o in cddl/lib/drti.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D22382
By using '__' instead of '.' as the separator we can also support systems
that use dash as /bin/sh (it's the default shell on Ubuntu/Debian). Dash
will unset any environment variables that use a non alphanumeric+undedscore
character and therefore submakes will fail to import the COMPILER_*
variables if we use '.' as the separator.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D22381
Don't depend on CPUTYPE to define powerpcspe CFLAGS, they should be set
unconditionally. This reduces duplication. Also, set some CFLAGS as
gcc-only, because clang's SPE support always uses the SPE ABI, it's not an
optional feature.
We will soon remove the BSD_CRTBEGIN option (and will use the new CRT
files always) as part of the GCC 4.2.1 removal. Right now BSD_CRTBEGIN
works everywhere but sparc64; add a reference to the PR in case anyone
stumbles across this and is looking for more information.
Add some diagnostic output.
This works around the fact that buildworld calls cleandir in libexec
with the wrong MACHINE_ARCH (i386 on amd64) when the OBJ directory is empty.
Reported by: bdragon, jkim
Alter bsd.compat.mk to set MACHINE and MACHINE_ARCH when included
directly so MD paths in Makefiles work. In the process centralize
setting them in LIBCOMPATWMAKEENV.
Alter .PATH and CFLAGS settings in work when the Makefile is included.
While here only support LIB32 on supported platforms rather than always
enabling it and requiring users of MK_LIB32 to filter based
TARGET/MACHINE_ARCH.
The net effect of this change is to make Makefile.libcompat only build
compatability libraries.
Changes relative to r354449:
Correct detection of the compiler type when bsd.compat.mk is used
outside Makefile.libcompat. Previously it always matched the clang
case.
Set LDFLAGS including the linker emulation for mips where -m32 seems to
be insufficent.
Reviewed by: imp, kib (origional version in r354449)
Obtained from: CheriBSD (conceptually)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22251
Alter bsd.compat.mk to set MACHINE and MACHINE_ARCH when included
directly so MD paths in Makefiles work. In the process centralize
setting them in LIBCOMPATWMAKEENV.
Alter .PATH and CFLAGS settings in work when the Makefile is included.
While here only support LIB32 on supported platforms rather than always
enabling it and requiring users of MK_LIB32 to filter based
TARGET/MACHINE_ARCH.
The net effect of this change is to make Makefile.libcompat only build
compatability libraries.
Reviewed by: imp, kib
Obtained from: CheriBSD (conceptually)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22251
Replace explicit TARGET_* variables with COMPAT_* versions defined based
on where the file is being included.
Also, require that bsd.compat.mk be included directly. It's not going to
be widely used so always loading it in bsd.prog.mk doesn't make sense.
Instead users can include it directly.
Reviewed by: imp, bdrewery (prior revision)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22059
Summary:
Historically, we have built toolchain components such as cc, ld, etc as
statically linked executables. One of the reasons being that you could
sometimes save yourself from botched upgrades, by e.g. recompiling a
"known good" libc and reinstalling it.
In this day and age, we have boot environments, virtual machine
snapshots, cloud backups, and other much more reliable methods to
restore systems to working order. So I think the time is ripe to flip
this default, and link the toolchain components dynamically, just like
almost all other executables on FreeBSD.
Maybe at some point they can even become PIE executables by default! :)
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22061
Linkage is controlled by two make knobs:
WANT_COMPAT - Prefer to link against the compat ABI.
NEED_COMPAT - Link against the compat ABI or fail to build.
Supported values are "32", "soft", and "any". The latter meaning pick
the first[0] supported compat ABI.
This can be used to provide test binaries for compat ABIs or to link
ABI-specific programs.
[0] We currently support only one compat ABI at a time, but this may
change in the future and some code in this commit is structured to ease
that change.
Reviewed by: bdrewery, jhb
Obtained from: CheriBSD (in concept)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22023
This will allow us to link against internal libraries when building
programs for the system's LIBCOMPAT ABI.
Reviewed by: bdrewery
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
This is the first step if refactoring the definitions to allow programs
to be selectively linked against libcompat libraries.
Reviewed by: bdrewery
Sponsored by: DARPA, AFRL
This provides a framework to define a template describing
a set of "variables of interest" and the intended way for
the framework to maintain them (for example the maximum, sum,
t-digest, or a combination thereof). Afterwards the user
code feeds in the raw data, and the framework maintains
these variables inside a user-provided, opaque stats blobs.
The framework also provides a way to selectively extract the
stats from the blobs. The stats(3) framework can be used in
both userspace and the kernel.
See the stats(3) manual page for details.
This will be used by the upcoming TCP statistics gathering code,
https://reviews.freebsd.org/D20655.
The stats(3) framework is disabled by default for now, except
in the NOTES kernel (for QA); it is expected to be enabled
in amd64 GENERIC after a cool down period.
Reviewed by: sef (earlier version)
Obtained from: Netflix
Relnotes: yes
Sponsored by: Klara Inc, Netflix
Differential Revision: https://reviews.freebsd.org/D20477
Diff partially stolen from CheriBSD; these bits need -Wl,-z,notext in order
to build in an LLVM world. They are needed for all flavors/sizes of MIPS.
This will eventually get fixed in LLVM, but it's unclear when.
Reported by: arichardson, emaste
Differential Revision: https://reviews.freebsd.org/D21696
GCC uses "dynamic" TLS models when -fpic or -fPIC is explicitly
specified on the command line (which is only true for shared libraries).
It uses "static" (or "exec") TLS models otherwise. In particular, GCC
does _not_ use dynamic TLS models when PIC is implicitly enabled (which
it is on MIPS), only if a PIC flag is explicitly provided.
llvm uses "dynamic" TLS models if PIC is enabled either via a PIC flag
or if it is implicily enabled (as on MIPS64). This means that llvm on
MIPS64 always uses "dynamic" TLS models. However, dynamic TLS models
do not work for static binaries and libraries as the __tls_get_addr
function they invoke is only defined in rtld.
Written by: jhb
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21699
This setup will add the trusted certificates from the Mozilla NSS bundle
to base.
This commit includes:
- CAROOT option to opt out of installation of certs
- mtree amendments for final destinations
- infrastructure to fetch/update certs, along with instructions
A follow-up commit will add a certctl(8) utility to give the user control
over trust specifics. Another follow-up commit will actually commit the
initial result of updatecerts.
This work was done primarily by allanjude@, with minor contributions by
myself.
No objection from: secteam
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16856
STAGE_DIR.${${_${group}DIR_${file}}:C,[/*],_,g} was getting
${STAGE_OBJTOP}BINDIR rather than
${STAGE_OBJTOP}${BINDIR} when FILESDIR=BINDIR
Reviewed by: stevek
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21858
picobsd/tinyware has had this compact HTTPD server for a long time, and some
people do use it. Move it out into usr.sbin well in advance of any action
being taken on picobsd.
This has been gated behind an HTTPD option defaulted to *off*, primarily for
two reasons:
1.) This code likely needs a good audit, as it's been living off in picobsd
land for a long time, and
2.) We don't currently ship an httpd and this may not be a welcome surprise.
Reviewed by: eugen
Differential Revision: https://reviews.freebsd.org/D21724
Summary: When powerpc64 switches to LLVM, use this patch to enable
OpenMP as well. OpenMP on PPC is only for 64-bits, so don't make a
32-bit libomp. A change to openmp files is necesssary (under review on
https://reviews.llvm.org/D67190), because it determines ELF format
version based on endianness, which is incorrect.
Reviewed by: alfredo.junior_eldorado.org.br, #manpages
Differential Revision: https://reviews.freebsd.org/D21532
chflags -R on it, otherwise the command will error out. (Note that
adding -f to the chflags invocation does not help, unlike with rm.)
MFC after: 3 days
Parts of the fusefs tests trigger a bug in current versions of llvm: IR
representation of some routine for the MIPS targets is a function with a
large number of arguments. This then leads the compiler on an hour+ long
goose chase, which is OK if you build the current tree but less-so if you're
trying external toolchain or doing a universe build involving mips when it
eventually gets switched over to LLVM.
Better, accurate details can be found in LLVM PR43263.
has become very trigger-happy with libc++ 9.0.0.
It does not help that gcc's implementation of this warning is even more
trigger-happy, in the sense that it already warns on the declaration
itself, not when you are using it. This is very annoying with our use
of -Wsystem-headers. That should really be disabled for gcc.
std::auto_ptr in a whole bunch of individual Makefiles, make the warning
globally non-fatal instead. This is similar to what was done to many
more non-fatal warnings from newer gcc versions.
Both clang and gcc development branches have reached version 10. Since we
only parse for a single digit in the major version number, this causes
COMPILER_VERSION to be set to its default of 0.0.0, meaning version checks
fail with these newer compilers.
Reviewed by: emaste
Approved by: markj (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D21413
We cannot use file (without :T) to name targets
but we can use the destination directory (with / replaced by _)
This has the benefit of minimizing the targets created.
Reviewed by: bdrewery
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org//D21283
The default package use to be FreeBSD-runtime but it should only contain
binaries and libs enough to boot to single user and repair the system, it
is also very handy to have a package that can be tranform to a small mfsroot.
So create a new package named FreeBSD-utilities and make it the default one.
Also move a few binaries and lib into this package when it make sense.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21506
As discussed on arch@, gcc 4.2.1 is on its way out. Turn off Werror on gcc
versions < 5.0 permantly. This will allow older platforms to continue to compile
w/o new errors once we take them out of universe by default. This will also free
developers from chasing down obsolete warnings that produce no beneficial
changes to the source.
Discussed on: arch@
Reviewed by: jhb@, emaste@, pfg@
Differential Revision: https://reviews.freebsd.org/D21378
In r342974 jhibbits added support to build crtsavres.o. This was the
blocker for BSD_CRTBEGIN to be enabled there. As such enable this
option again.
Reviewed by: jhibbits
Sponsored by: DARPA, AFRL
It is part of -Wformat, which is enabled by -Wall. Empty format strings are
well defined and it is perfectly reasonable to expect them in a formatting
interface.
Don't mark nvme as broken on aarch64. It compiles, at least, and people are
testing it out. This only enables the userland parts of the nvme stack.
Submitted by: greg at unrelenting technologies
Differential Revision: https://reviews.freebsd.org/D21168
Having the full uname output can be useful on head even with
unmodified trees or trees that newvers.sh fails to recognize as
modified.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D20895
Some warning flags are valid for C++ but not C. GCC 8 complains if you pass
such flags when building a C file. Using a separate variable for these
flags allows building both C and C++ files in the same directory (such as
the fusefs tests) under GCC.
Reviewed by: cem, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21116
Now that we have a way to obtain entropy in capability mode
(getrandom(2)), libcap_random is obsolete. Remove it.
Bump __FreeBSD_version in case anything happens to use it, though I've
found no consumers.
Reviewed by: delphij, emaste, oshogbo
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21033
This will be used to gate the fusefs tests. It's a partial merge of r348281
from projects/fuse2.
Reviewed by: kib, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21044
Allow ABI to be over ridden to allow (with other changes) programs to be
built targeting ABIs other than the default. This is used in CheriBSD.
Reviewed by: imp
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21001
This reworks my last commit in r301285 to more closely match what was in
r241298 (but reverted in r294878).
This is addressing "missing .meta file" rebuilds but also ensuring that
files are always generated when needed in each case.
Note that this is not a complete rework of the problem areas identified
in r301285 as most are "good enough" right now as the new pattern
is too verbose. It's only worth making this current change where headers
may be generated in the INCS list; where missing .meta file rebuilds are
spotted.
--- Technical details follow ---
Several attempts to deal with this problem of multi-output targets, with and
without META MODE, were explained in r241298, r294878, and r301285.
The general problem is with multi-output targets such as:
foo.c foo.h:
touch foo.c foo.h
foo.c foo.h:
touch foo.c
touch foo.h
foo.c foo.h: foo.in
./generator ${.ALLSRC}
This pattern is problematic in jobs mode as both files end up being
built concurrently and leads to races. With META MODE it is worse
as both targets end up rebuilding if they lack a .meta file. So the
generator is force built twice even though it is only needed once.
There are also problems in that 'make foo.h' may be ran before 'make foo.c';
The order of make generating the targets is not guaranteed.
An older attempted workaround to this (discussed in r294878) was:
foo.h: foo.c
foo.c: foo.in
./generator ${.ALLSRC}
This appears fine except that if foo.h is missing and foo.c exists then
foo.h will never be regenerated. This pattern is close to the solution
in this commit though:
foo.h: foo.c .NOMETA
.if !exists(foo.h)
foo.c: .PHONY .META
.endif
foo.c: foo.in
./generator ${.ALLSRC}
There's 2 differences here:
1. foo.h will never expect to have a .meta file since the foo.c target
will generate both and own the .meta file.
2. If foo.h does not exist then it needs to force foo.c to be rebuilt
with .PHONY. That normally disables META MODE though so .META is
given to tell bmake we do really expect a .meta file.
This pattern cannot work with implicit suffix rules since the .c and .h files
may be generated at different times (buildincludes vs depend/all).
Sponsored by: Dell EMC
MFC after: 2 weeks
This change was originally in D20378. Making it in a new diff since it's a
bugfix.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: emaste, luporl
Differential Revision: https://reviews.freebsd.org/D20756
NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.
Numerous posts to arch@ and other locations have found no actual users
for this software.
Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745
Summary:
Toolchain follow-up to r349350. LLVM patches will be submitted upstream for
9.0 as well.
The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it
cannot determine for certain that it needs Secure-PLT, and some binaries do
not compile in such a way to make it know to use Secure-PLT.
Reviewed By: nwhitehorn, bdragon, pfg
Differential Revision: https://reviews.freebsd.org/D20598
This is still targeting bin/sh cyclic dependency issues. Only apply
guessed dependencies that are explicitly set for an object (which
gnu/lib/cc/cc_tools needs) and if no custom target exists with its
own dependencies.
This was manifesting as a missing yacc.h in usr.bin/mkesdb_static when
built without -j (or -B). No actual yacc.h dependency ordering was
defined but with -j it got lucky and built fine.
Before r349061 the behavior was different for META_MODE but that logic
difference isn't needed.
X-MFC-With: r349061
Sponsored by: DellEMC
Default to tracking .depend.* for OBJS rather than SRCS.
This helps cover some special case builds like gnu/lib/csu which
do more of a PROGS-like thing with bsd.prog.mk.
It is possible this causes out-of-tree Makefiles to have problems if they use
this pattern:
foo.o: foo.c
${CC} -o ${.TARGET} ${.ALLSRC}
This may cause multiple source files to be compiled due to finding the
'foo.o: foo.c' dependency both in the Makefile at the .depend file. Or
it may try compiling headers. This can be worked around by either of these:
foo.o: foo.c
${CC} -o ${.TARGET} ${.ALLSRC:N*.h:[1]}
Or
foo.o: foo.c
${CC} -o ${.TARGET} ${.CURDIR}/foo.c
In the latter case the ${.CURDIR} may need to be a different path. The
first case covers automatically using .PATH.
Sponsored by: DellEMC
If a meta mode change is triggered but then the build fails then the
next build will not retrigger meta mode. This only prevented by
removing the target on rebuild or on the failure to rebuild.
Sponsored by: DellEMC
This is in the case of not having any .depend.foo.o yet. Don't force add *.h
as a dependency for those. They are built in beforebuild already when in
SRCS/DPSRCS.
This change allows custom rules, like in bin/sh/Makefile for mksyntax, to not
have cyclic dependency problems when connected to the .depend.* handling.
This is purposely not copied to sys/conf/kern.post.mk as it handles
generating headers slightly differently.
MFC after: 2 weeks
Sponsored by: DellEMC
r345708 worked for the base system, but unfortunately, caused a lot of
disruption for third-party packages that relied on C++, since bsd.sys.mk is
used by applications outside the base system. The defaults picked didn't match
the compiler's defaults and broke some builds that didn't specify a standard,
as well as some that overrode the value by setting `-std=gnu++14` (for
example) manually.
This change takes a more relaxed approach to appending `-std=${CXXSTD}` to
CXXFLAGS, by only doing so when the value is specified, as opposed to
overriding the standard set by an end-user. This avoids the need for having
to bake NOP default into bsd.sys.mk for supported compiler-toolchain
versions.
In order to make this change possible, add CXXSTD to Makefile snippets which
relied on the default value (c++11) added in r345708.
MFC after: 2 weeks
MFC with: r345708, r346574
Reviewed by: emaste
Reported by: jbeich
Differential Revision: https://reviews.freebsd.org/D19895 (as part of a larger change)
The current approach of injecting manifest into mac_veriexec is to
verify the integrity of it in userspace (veriexec (8)) and pass its
entries into kernel using a char device (/dev/veriexec).
This requires verifying root partition integrity in loader,
for example by using memory disk and checking its hash.
Otherwise if rootfs is compromised an attacker could inject their own data.
This patch introduces an option to parse manifest in kernel based on envs.
The loader sets manifest path and digest.
EVENTHANDLER is used to launch the module right after the rootfs is mounted.
It has to be done this way, since one might want to verify integrity of the init file.
This means that manifest is required to be present on the root partition.
Note that the envs have to be set right before boot to make sure that no one can spoof them.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19281
This is particularly useful when installing programs for tests that need to be
linked statically, e.g., mini-me from capsicum-test, which is linked statically
to avoid the dynamic library lookup in the upstream project.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19756
The behavior prior to this change would not override default values if set in
`bsd.own.mk`, or (in the more general case) globally before `bsd.progs.mk` was
included. This affected `bsd.test.mk` as well, since it consumes
`bsd.progs.mk`.
Some examples of this failing behavior are as follows:
* `BINMODE` defaults to 0555 per `bsd.own.mk`. If someone wanted to set the
`BINMODE` to `NOBINMODE` (0444) for `prog`, for example, like
`BINMODE.prog= ${NOBINMODE}`, `bsd.progs.mk` would not honor the per-PROG
setting.
* An application, `prog`, does not build at `WARNS?= 6`. Before this change,
setting to a lower `WARNS` value, e.g., `WARNS.prog= 3`, would have been
impossible, requiring that `prog` be built from another directory,
the global `WARNS` be lowered, or a per-PROG value needing to be set
across the board. None of the above workarounds is desirable.
This change unbreaks variables defined in `PROG_OVERRIDE_VARS` which have
defaults set before `bsd.progs.mk` is included, by setting them to their
defined values if set on a per-PROG basis.
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19755
The current logic for CSTD/CXXSTD requires homogenity as far as the
supported C/C++ standards, which is a sensible default. However, when
dealing with differing versions of C++, some code may compile with C++11, but
not C++17 (for instance). So in order to avoid having people convert over their
code to the new standard, give the users the ability to specify the standard on
a per-program basis.
This will allow a user to override the supporting standard for a set of
programs, mixing C++11 with C++14 (for instance).
Reviewed by: asomers
Apprved by: emaste (mentor)
MFC after: 1 month
MFC with: r345708
Differential Revision: https://reviews.freebsd.org/D19738
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
When a review is closed via Phabricator it updates the patch attached to the
review. I downloaded the raw patch from Phabricator, applied it, and repeated
my mistake from r345704 by accident mixing content from D19732 and D19738.
For my own personal sanity, I will try not to mix reviews like this in the
future.
MFC after: 1 month
MFC with: r345706
Approved by: emaste (mentor, implicit)
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
I accidentally committed code from two reviews. I will reintroduce the code to
bsd.progs.mk as part of a separate commit from r345704.
Approved by: emaste (mentor, implicit)
MFC after: 2 months
MFC with: r345704
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19732
This makes it easier for googletest users to leverage googletest, instead of
forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in
unnecessary duplication).
I will be following this up with a more proper fix in src.libnames.mk, as
src.libnames.mk should be automatically adding this directory to
CFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can result
in mismatches between base-provided private library's and ports-provided
library's headers.
While here, tweak the comment to clarify what the intent is behind spamming
CXXFLAGS.
MFC after: 5 weeks
MFC with: r345203
Reported by: asomers
Reviewed by: asomers
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D19731
This was missed in r342139 when timed(8) was removed and fixes a
warning when running makeman to regenerate src.conf.5.
Differential Revision: https://reviews.freebsd.org/D19486
* Set MK_OPENMP to yes by default only on amd64, for now.
* Bump __FreeBSD_version to signal this addition.
* Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes.
* Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h.
* Regenerate src.conf(5) with new WITH/WITHOUT fragments.
Relnotes: yes
PR: 236062
MFC after: 1 month
X-MFC-With: r344779
This initial integration takes googlemock/googletest release 1.8.1, integrates
the library, tests, and sample unit tests into the build.
googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`.
`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when
built with a C++11 capable toolchain.
Google tests can be specified via the `GTESTS` variable, which, in comparison
with the other test drivers, is more simplified/streamlined, as Googletest only
supports C++ tests; not raw C or shell tests (C tests can be written in C++
using the standard embedding methods).
No dependent libraries are assumed for the tests. One must specify `gmock`,
`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.
More information about googlemock and googletest can be found on the
Googletest [project page](https://github.com/google/googletest), and the
[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)
and
[GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)
docs.
These tests are originally integrated into the build as plain driver tests, but
will be natively integrated into Kyua in a later version.
Known issues/Errata:
* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19551
This permits legacy GDB to still be built and installed if
WITHOUT_BINUTILS is set (e.g. if base/binutils is installed).
Reviewed by: emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D19480
UEFI related headers were copied from edk2.
A new build option "MK_LOADER_EFI_SECUREBOOT" was added to allow
loading of trusted anchors from UEFI.
Certificate revocation support is also introduced.
The forbidden certificates are loaded from dbx variable.
Verification fails in two cases:
There is a direct match between cert in dbx and the one in the chain.
The CA used to sign the chain is found in dbx.
One can also insert a hash of TBS section of a certificate into dbx.
In this case verifications fails only if a direct match with a
certificate in chain is found.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19093
Instead of PRIVATELIB + NO_PIC. This avoids the need for the wlandebug
PIE special case added in r344211, and provides a stronger guarantee
against 3rd party software coming to depend on the API or ABI.
If / when we declare the API/ABI to be stable we can make it a normal
library.
Discussed with: bapt
Sponsored by: The FreeBSD Foundation
The move to /usr/include/private prefixed paths seems to require a bit more
effort in order to compile programs.
Install the headers to /usr/include/private/g{mock,test}/... and automatically
include /usr/include/private in GTESTS_CXXFLAGS to make compilation seamless. I
will work on the more global problem later with @bdrewery.
A previous iteration referenced/used googletest.test.flags.mk, not
googletest.test.inc.mk. The latter name is what I settled on as this
Makefile snippet can include more logic than flags.
Long story short, some of the tests were failing because they expected either
dynamic_cast or RTTI to be functional and it wasn't.
Move all common CXXFLAGS out to googletest.test.inc.mk and reference it from
googletest.test.mk and .../googletest/Makefile.inc
googletest.test.mk is a rudimentary wrapper around the plain test interface
(for now), which only supports C++ programs, specified by the `GTESTS`
variable.
In the future, kyua will support gtests in a more native manner.
These libraries don't compile on non-C++-11 capable compilers, e.g., g++ 4.2.1
and its corresponding implementation of the c++ library, i.e., libstdc++.
Blacklist compilation on all non-C++-11 capable compilers and give others the
option of opting out of building/installing gmock/gtest via MK_GOOGLETEST.
This option is controlled by MK_CXX and MK_TESTS, as ATF compilation is.
Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).
With this change PIE objects have a .pieo extension and INTERNALLIB
libraries libXXX_pie.a.
MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as
they explicitly reference .a libraries in their Makefiles. These can
be addressed on an individual basis later. MK_PIE is also disabled for
rtld-elf because it is already position-independent using bespoke
Makefile rules.
Currently only dynamically linked binaries will be built as PIE.
Discussed with: dim
Reviewed by: kib
MFC after: 1 month
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18423
The MPC8540 is actually e500v1, which doesn't have double-precision floating
point support. The 8548 does, so use that as the CPU target.
MFC after: 2 weeks
The logic I introduced in r322511 unfortunately left chflags schg'ed
directories behind created by `make hier` (in the stock /etc/mtree
files, this is limited to /var/empty).
The proposed change calls `chflags -R 0` and `rm -Rf ...` to clean all
of the directories that could not be removed by `${MAKE} clean`.
`${MAKE} clean` in bsd.obj.mk calls `cleandir`/`cleanobj`, which handles
the first directory tree walk/removal.
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18641
The migration to LLVM's lld linker has been in progress for quite some
time - I opened an LLVM tracking bug (23214) in April 2015 to track
issues using lld as FreeBSD's linker, and requested the first exp-run
using lld as /usr/bin/ld in November 2016.
In 12.0 LLD is the system linker on amd64, arm64, and armv7. i386 was
not switched initially as there were additional ports failures not found
on amd64. Those have largely been addressed now, although there are a
small number of issues that are still being worked on. In some of these
cases having lld as the system linker makes it easier for developers and
third parties to investigate failures.
Thanks to antoine@ for handling the exp-runs and to everyone in the
FreeBSD and LLVM communites who have fixed issues with lld to get us to
this point.
PR: 214864
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
bsd.{files,conf}.mk recently changed to allow *DIR to name a variable
rather than a path.
STAGE_DIR.* need to adapt.
Reviewed by: bdrewery
Differential Revision: D18847
to shrink libllvm.a.
This is a workaround for "relocation truncated to fit" errors with BFD
ld 2.17.50 on arm and armv6, when linking executables against it.
The required range extensions are not yet supported by this very old
version of BFD ld. When arm and armv6 userland can be successfully
linked by lld, this workaround can be removed.
It has passed an exp run on amd64 and i386, and has testing on arm64. On
other architectures it is expected to run, however it can be disabled by
building world with -DWITHOUT_BSD_CRTBEGIN.
Sponsored by: DARPA, AFRL
And build libdl unconditionally. All supported FreeBSD linkers accept
-F / --filter so there is no need to test for support.
Discussed with: kib
Sponsored by: The FreeBSD Foundation
cap_fileargs is a Casper service which helps to sandbox applications that need
access to the filesystem namespace. The main purpose of the service is to make
easy to capsicumize applications that works on multiple files passed in argv.
We have a couple example of using it but we still treat this service as an
experimental one.
Reviewed by: emsate (previous version), jonathan (partially)
Discussed with: many
Differential Revision: https://reviews.freebsd.org/D14407
The BSD crtbegin/crtend code now builds on all architectures, however
further work is needed to check if it works correctly.
MFC with: r339738
Sponsored by: DARPA, AFRL
The linker's -z now flag sets the DF_BIND_NOW flag, which signals to the
runtime loader that all relocation processing should be performed at
process startup rather than on demand. In combination with lld's
default of enabling relro this causes the GOT to be made read-only when
the process starts, preventing straightforward GOT overwrite attacks.
Shawn Webb discovered a failure on HardenedBSD with BIND_NOW and ifunc
use, which resulted in my rtld fix in r340137. Add a BIND_NOW knob as
it is trivial to do so and is a useful ELF hardening feature. This
change is equivalent to HardenedBSD's but not identical as there are
other diffs/conflicts nearby.
Note that our ELF Tool Chain readelf does not currently decode the
DF_BIND_NOW flag - see PR232983.
Reviewed by: brooks
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17846
You should not be using DES. You should not have been using DES for the
past 30 years.
The ed DES-CBC scheme lacked several desirable properties of a sealed
document system, even ignoring DES itself. In particular, it did not
provide the "integrity" cryptographic property (detection of tampering), and
it treated ASCII passwords as 64-bit keys (instead of using a KDF like
scrypt or PBKDF2).
Some general approaches ed(1) users might consider to replace the removed
DES mode:
1. Full disk encryption with something like AES-XTS. This is easy to
conceptualize, design, and implement, and it provides confidentiality for
data at rest. Like CBC, it lacks tampering protection. Examples include
GELI, LUKS, FileVault2.
2. Encrypted overlay ("stackable") filesystems (EncFS, PEFS?, CryptoFS,
others).
3. Native encryption at the filesystem layer. Ext4/F2FS, ZFS, APFS, and
NTFS all have some flavor of this.
4. Storing your files unencrypted. It's not like DES was doing you much
good.
If you have DES-CBC scrambled files produced by ed(1) prior to this change,
you may decrypt them with:
openssl des-cbc -d -iv 0 -K <key in hex> -in <inputfile> -out <plaintext>
Reviewed by: allanjude, bapt, emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D17829
This will no work when there is no cc in $PATH (which is the case before the
cross-tools stage once we no longer inherit $PATH in $WMAKE).
The variables set by bsd.compiler.mk/bsd.linker.mk are not needed in these
stages so this avoids a little bit of makefile parsing.
Reviewed By: emaste
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D16814
In the last decade(s) we have seen both short term or long term projects
committed to the tree which were considered or even marked "experimental".
While out-of-tree development has become easier than it used to be in
CVS times, there still is a need to have the code shipping with HEAD but
not enabled by default.
While people may think about VIMAGE as one of the recent larger, long term
projects, early protocol implementations (before they are standardised)
are others. (Free)BSD historically was one of the operating systems
which would have running code at early stages and help develop and
influence standardisation and the industry.
Give developers an opportunity to be more pro-active for early adoption
or running large scale code changes stumbling over each others but not
the user's feet. I have not added the option to NOTES in order to avoid
breaking supported option builds, which require constant compile testing.
Discussed with: people in the corridor
These are needed for .ctors/.dtors and .jcr handling. The former needs
all the function pointers to be called in the correct order from the
.init/.fini section. The latter just needs to call a gcj specific function
if it exists with a pointer to the start of the .jcr section.
This is currently disabled until __dso_handle support is added.
Reviewed by: emaste
MFC after: 1 month
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D17587
When building CheriBSD we have to set XLD/XCC/XCFLAGS on the command line.
This triggers the $XCC != $CC case in bsd.compiler.mk (and the same for LD
in bsd.linker.mk) which causes it to call ${XCC} --version and
${XLD} --version (plus various awk+sed+echo calls) in every subdirectory.
For incremental builds and stages that only walk the source tree this is
often the majority of the time spent in that directory.
By only computing the value of the X_COMPILER_*/X_LINKER_* variables if
_WANT_TOOLCHAIN_CROSS_VARS is set we can reduce the number of cc/ld calls
to once per build stage instead of once per recursive make.
With this change (and no changes to the sources) the `make includes` stage
now takes 28 seconds at -j1 instead of 86 seconds.
Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D17046
__DEFAULT_YES/NO. These options simply cannot work where we were using
__DEFAULT_NO. The proper thing to do in that case is to use the
BROKEN_OPTIONS knob instead.
it appropriately when building share/ctypedef and share/colldef.
This makes the resulting locale data in EL->EB (amd64->powerpc64) cross
build and in the native EB build match. Revert the changes done to libc
in r308170 as they are no longer needed.
PR: 231965
Reviewed by: bapt, emaste, sbruno, 0mp
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D17603
well as on SPARC64 and can cause boot failures even when no encrypted
disks are present. Presumably, the reasons, while unknown, are the same
and most-likely are the result of some endian-unsafe code. Pending
finding the actual problem, extend the blacklist entry for these parts
of loader on SPARC to also cover all PowerPC platforms.
Approved by: re (kib)
Without this we get spurious output during boot as we try to run
nonexistant HyperV scripts on non-x86 models.
Reviewed by: kib
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D17211
- Warn if multiple DIRS have conflicting metadata
- This fixes META_MODE writing to a very long .meta file that contained
the full DESTDIR path.
Reported by: sjg, jonathan
Sponsored by: Dell EMC
Approved by: re (gjb)
We want to build the 12.0 release artifacts with reproducible builds
mode enabled. Switch it on in HEAD now to enable testing with upcoming
ALPHA builds. We can revisit the default setting for HEAD after the
branch is created.
This change eliminates the build metadata (user, hostname, timestamp,
etc.) from the kernel and loader. If the src tree is a git, svn or p4
checkout with changes then the metadata is retained.
The WITHOUT_REPRODUCIBLE_BUILD src.conf(5) knob can be used to revert
to the previous behaviour.
Approved by: re (gjb)
Sponsored by: The FreeBSD Foundation
This was disabled recently due to lack of support in KDB disassembler
and DTrace FBT provider. Support for 'C'-extension to both of these was
added, so we can now enable 'C'-extension.
This reduces size of the kernel important for low-end embedded devices,
and saves cache footprint for high perfomance machines.
Approved by: re (kib)
Sponsored by: DARPA, AFRL
