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
are fully debugged. With these options off, the unified "loader"
binary for sparc64 works to boot a kernel from ZFS.
Submitted by: kevans
Reviewed by: imp kevans
Some background: in the GSoC project, libbe/Makefile lived in lib/libbe. I
created projects/bectl branch, maintained the above for all of five
minutes before I misread Makefile.inc1 and decided that it couldn't possibly
build outside of cddl/, so I kicked the Makefile out into the cddl/ build
and all was good. The misreading was of the bit where .WAIT is added to
SUBDIR after lib, libexec but prior to building bin and cddl *only during
the install targets*, which is the critical part.
Fast forward- buildworld was still broken in my branch unbeknownst to me
because I didn't nuke my OBJDIR. Combing through Makefile.inc1 eventually
revealed the necessary magic to make sure that libbe's dependencies are
specified well enough, and it becomes clear what needs done to make a
non-cddl/ build work. This is an interesting prospect, because the build
split is kind of annoying to work with.
IGNORE_PRAGMA is added to avoid dropping WARNS by one more. This was
previously pulled in via cddl/Makefile.inc.
lld should now be a usable linker for armv7, and is already used as the
bootstrap linker (for linking the kernel and userland). Also enable as
the system linker now (/usr/bin/ld) for further testing and evaluation.
(This change will be reverted in case of unexpected fallout.)
Approved by: manu
Sponsored by: The FreeBSD Foundation
Create loader_{4th,lua,simp}{,.efi}. All of these are installed by
default. Create LOADER_DEFAULT_INTERP to specify the default
interpreter when no other is specified. LOADER_INTERP is the current
interpreter language building. Turn building of lua on by default to
match 4th. simploader is a simplified loader build w/o any interpreter
language (but with a simple loader). This is the historic behavir you
got with WITHOUT_FORTH. Make a hard link to the default loader. This
has to be a hard link rather than the more desirable soft link because
older zfsboot blocks don't support symlinks.
RelNotes: Yes
Differential Revision: https://reviews.freebsd.org/D16705
BPF (eBPF) is an independent instruction set architecture which is
introduced in Linux a few years ago. Originally, eBPF execute
environment was only inside Linux kernel. However, recent years there
are some user space implementation (https://github.com/iovisor/ubpf,
https://doc.dpdk.org/guides/prog_guide/bpf_lib.html) and kernel space
implementation for FreeBSD is going on
(https://github.com/YutaroHayakawa/generic-ebpf).
The BPF target support can be enabled using WITH_LLVM_TARGET_BPF, as it
is not built by default.
Submitted by: Yutaro Hayakawa <yhayakawa3720@gmail.com>
Reviewed by: dim, bdrewery
Differential Revision: https://reviews.freebsd.org/D16033
large atomic operation may incur significant performance penalty" ) for
arm before armv6. Since on these older architectures atomic operations
are always translated to libcalls, and this is expected, the warning is
not really useful there.
dirdeps.mk and meta.autodep.mk will now look for
Makefile.depend.options
to handle optional dependencies, the work is all done by
dirdeps-options.mk
Also update to latest meta.stage.mk and gendirdeps.mk
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D15701
As of r336972 lld is capable linking the armv7 kernel and userland,
so enable it by default.
PR: 229050
Reviewed by: kevans
Tested by: kevans
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16528
By default ld.lld should be the bootstrap linker (only) on i386 right
now. Once the i386 exp-run with LLD_IS_LD has a good result this will
also be enabled by default.
Reported by: andrew
Pointy hat to: emaste
Akin to r327783 for amd64. lld has been usable for amd64 for quite some
time, but a couple of issues remained that affected i386. These were
recently addressed upstream in lld and merged into FreeBSD or addressed
directly in FreeBSD (r326831, r326879, r326897, r326957, r333401,
r334626, r336664).
Similarly to the intial amd64 commit this change enables lld only as the
bootstrap linker (used to link the kernel and userland libraries and
executables), while GNU ld.bfd is still installed as /usr/bin/ld and
used for ports builds. That will be changed shortly, after an exp-run.
This is a recommit of r327823 after additional lld fixes.
PR: 225128 (exp-run)
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
The padding makes it much easier to read, but occasionally means that commits
like this one have to be done to follow up. I intentionally kept this
separate from r336841 to try and make things easier to follow later on.
Approved by: bapt (mentor)
r336773 removed all things xscale. However, some things xscale are
really armv5. Revert that entirely. A more modest removal will follow.
Noticed by: andrew@
The OLD XSCALE stuff hasn't been useful in a while. The original
committer (cognet@) was the only one that had boards for it. He's
blessed this removal. Newer XSCALE (GUMSTIX) is for hardware that's
quite old. After discussion on arm@, it was clear there was no support
for keeping it.
Differential Review: https://reviews.freebsd.org/D16313
target.
Also update the pfctl tests Makefile to work with this change.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D16430
It works excellent, but KDB disassembler and DTrace FBT provider for
RISC-V do lack support for it. They currently handle 4-byte instructions
only, while C-compressed ISA extension introduces 2-byte instructions
freely mixing them together.
So disable it for now.
Reviewed by: markj@
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16436
This paves the way for moving config files out of head/etc and into the
directories with the src.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D16406
Perhaps using libbe.a from "${DESTDIR}${LIBDIR}" might have been the
prevailing technique at one point, but nowadays it appears to be to
preferred to spell this as "${OBJTOP}/lib" -- make it so.
This moves the bulk of the geli support from lib386/biosdisk.c into a new
geli/gelidev.c which implements a devsw-type device whose dv_strategy()
function handles geli decryption. Support for all arches comes from moving
the taste-and-attach code to the devopen() function in libsa.
After opening any DEVT_DISK device, devopen() calls the new function
geli_probe_and_attach(), which will "attach" the geli code to the open_file
struct by creating a geli_devdesc instance to replace the disk_devdesc
instance in the open_file. That routes all IO for the device through the
geli code.
A new public geli_add_key() function is added, to allow arch/vendor-specific
code to add keys obtained from custom hardware or other sources.
With these changes, geli support will be compiled into all variations of
loader(8) on all arches because the default is WITH_LOADER_GELI.
Relnotes: yes
Sponsored by: Microchip Technology Inc
Differential Revision: https://reviews.freebsd.org/D15743
to be displayed when make is called with -s. Replace it by ${ECHO}.
Reviewed by: brd, bdrewery
Approved by: brd, bdrewery
Sponsored by: Rubicon Communications, LLC (Netgate)
Differential Revision: https://reviews.freebsd.org/D16195
Add src.conf knob to disable the installation of /var/db/services.db
Default to leaving services.db in place, but allow the removal of the
file and its creation with a src.conf knob.
This file ends up being 2MB in size. For small systems this is a waste
of space but its a tradeoff.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D9655
ACFLAGS is only used in addition to CFLAGS, so setting the options in
both was redundant. However, ACFLAGS is added to the command line
after CFLAGS, so the settings from ACFLAGS were applied for assembly
files in kernel modules after the kernel-specific march/abi in CFLAGS.
As a result, the hard-float ACFLAGS in bsd.cpu.mk was overriding the
soft-float CFLAGS.gcc in sys/conf/kern.mk. In particular,
dtrace_asm.o was compiled as hard-float and the linker refused to link
dtrace.ko since its object files contained a mix of hard and soft
float.
Reviewed by: br
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D16054
For developers gensnmptree can now generate functions for enums to convert
between enums and strings and to check the validity of a value.
The sources in FreeBSD are now in sync with the upstream which allows to
bring in IPv6 modifications.
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
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
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
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
installworld should not be executing this anyhow but there is some
obscure case doing it still. The head(1) binary is not part of
ITOOLS and there's no need to add it.
MFC after: 1 week
Sponsored by: Dell EMC
The migration to LLVM's lld linker has been in progress for quite some
time - about three years ago I opened an upstream LLVM meta-bug to track
issues using lld as FreeBSD's linker, and about 1.5 years ago requested
the first exp-run with lld as the system linker.
As of r327783 we enabled LLD_BOOTSTRAP by default on amd64, using lld as
the linker to link the kernel and world, but GNU ld was still installed
as /usr/bin/ld.
The vast majority of issues observed when building ports with lld as the
system linker have now been solved, so set LLD_IS_LD by default on amd64
and install lld as /usr/bin/ld. A small number of port failures remain
and these will be addressed in the near future.
Thanks to antoine@ for handling the exp-runs, krion@ for investigating
many port failures and adding LLD_UNSAFE or other fixes or workarounds,
and everyone who helped investigate, fix or tag ports.
PR: 214864 (exp-run)
Sponsored by: The FreeBSD Foundation
The rescue/crunchgen build avoids linking binaries for the objects it is
building by doing 'make foo.o bar.o' rather than 'make all'. This breaks the
implicit 'beforebuild: depend' dependency which ensured that all source files
were generated and up-to-date before building the object files. This
manifested as a WITH_META_MODE build problem for bin/sh in the rescue build
with syntax.{c,h} not properly being regenerated or recognized as changed in
the dependency graph.
Sponsored by: Dell EMC
MFC after: 1 week
Reported by: many
freebsd-update depends on phttpget from portsnap. We could move phttpget
out of portsnap and build it as long as WITHOUT_FREEBSD_UPDATE and
WITHOUT_PORTSNAP are not both set, but for now just make the dependency
explicit.
PR: 228220
Reported by: Dries Michiels
Sponsored by: The FreeBSD Foundation
Libcasper and its modules have no static libraries so don't define
paths to them. This fixes LIBADD automatically adding DPADD
entries for casper.
Reported by: sbruno
Sponsored by: Dell EMC Isilon
As of r333461 we require ifunc support to link a working amd64 kernel.
The default in-tree bootstrap linker is lld and it has the required
support, as does any modern out-of-tree binutils linker. The in-tree
GNU ld is from binutils 2.17.50 and it does not have ifunc support,
so produce an error rather than a broken kernel.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15378
The existing patterns for 'cc --version' output do not work for GCC
built from the base/gcc port.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D15357
This is part of packaging base work.
Reviewed by: will
Approved by: bapt (mentor), allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D15130
Rtld is not compatible with SSP, and since we link libc_pic.a to rtld
to have the basic support like memory and string copy functions, we
have to both carefully limit libc use, and to provide the ssp support
shims. This change makes the libc use in rtld more straighforward but
still limited, and allows to remove the shims, to be done in the next
commit.
Submitted by: Luis Pires
Reviewed by: bdrewery, brooks
Differential revision: https://reviews.freebsd.org/D15283
warning:
make[3]: "/usr/src/share/mk/bsd.prog.mk" line 274: warning: duplicate
script for target "_scriptsinstall" ignored
make[3]: "/usr/src/share/mk/bsd.prog.mk" line 274: warning: using
previous script for "_scriptsinstall" defined here
Reviewed by: kevans
It was an old TRE that had plenty of bugs and no performance gain over
regex(3). I disabled it by default in r323615, and there was some confusion
about what the knob does- likely due to poor naming on my part- to the tune
of "well, it sounds like it should speed things up" (mentioned by multiple
people).
To compound this, I have no intention of maintaining a second regex
implementation. If someone would like to step up and volunteer to maintain a
lean-and-mean implementation for grep, this is OK, but we have very few
volunteers to maintain even our primary regex implementation.
As with Clang, build our toolchain components by default when the host
compiler is capable of doing so, to make them available for testing and
experimentation.
Sponsored by: The FreeBSD Foundation
r332090 added a LINKER_TYPE test to add the --no-rosegment flag when
linking the i386 loader components with lld. Instead, introduce a
general mechanism for setting LDFLAGS for a specific linker type,
and use it for --no-rosegment.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14998
__riscv_float_abi_double macro will be defined by compiler.
The options are:
o lp64 __riscv_float_abi_soft
o lp64f __riscv_float_abi_single
o lp64d __riscv_float_abi_double
Sponsored by: DARPA, AFRL
This was inadvertently overriding the first found SYSDIR with the last
of /usr/src which could result in the wrong headers being used if not
building from /usr/src.
SYSDIR?= is not used here to avoid evaluating the exists() when unneeded.
Reported by: rgrimes, sjg, Mark Millard
Pointyhat to: bdrewery
Sponsored by: Dell EMC
These have become unsorted from everything else. This is desync'd from
stable/11 due to some hand-merging that was done there, so the MFC of this
will look slightly different.
MFC after: 3 days
OpenCSD is an ARM CoreSight(tm) trace packets decoder.
- Connect libopencsd to the arm64 build.
- Install opencsd headers to /usr/include/opencsd/
Sponsored by: DARPA, AFRL
DTB Overlays are useful to change/add nodes to a dtb without the need to
modify it.
Add support for building dtbo during buildkernel.
The goal of DTBO present in the FreeBSD source tree is to fill a gap in
time when we submit changes upstream (Linux). Instead of waiting 2 to 4 months
we can add a DTBO in tree in the meantime.
This is not for adding DTBO for capes/hat/addon boards, those will be
better to put in a ports.
This is also not for enabling a i2c/spi/pwm controller on certain pins,
each user have a different use case for those (which pins to use etc ...)
and we cannot have all possible configuration.
Add a dtbo for sun8i-h3-sid which add the SID node missing in upstream dts.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D14782
This is originally based on a patch from David Chisnall for soft-float
N64 but has since been updated to support O32, N32, and hard-float ABIs.
The soft-float O32, N32, and N64 support has been committed upstream.
The hard-float changes are still in review upstream.
Enable LLVM_LIBUNWIND on mips when building with a suitable (C+11-capable)
toolchain. This has been tested with external GCC for all ABIs and
O32 and N64 with clang.
Reviewed by: emaste
Obtained from: CheriBSD (original N64 patch)
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D14701
ConnectX-4/5 devices in mlx5core.
The dump is obtained by reading a predefined register map from the
non-destructive crspace, accessible by the vendor-specific PCIe
capability (VSC). The dump is stored in preallocated kernel memory and
managed by the mlx5tool(8), which communicates with the driver using a
character device node.
The utility allows to store the dump in format
<address> <value>
into a file, to reset the dump content, and to manually initiate the
dump.
A call to mlx5_fwdump() should be added at the places where a dump
must be fetched automatically. The most likely place is right before a
firmware reset request.
Submitted by: kib@
MFC after: 1 week
Sponsored by: Mellanox Technologies
LLD is a cross toolchain component. It shouldn't be built when
requesting a build without building a cross compiler.
(CROSS_COMPILER is somewhat unfortunately named; in any case, lld
should be treated as GNU binutils here.)
Submitted by: Dan McGregor <dan.mcgregor at usask.ca>
MFC after: 1 week
A sub-make, such as in 'make buildworld', may want to override MAKEOBJDIRPREFIX
but is unable to do so if src-env.conf is forcing it to another value. Without
using '?=' the sub-make may use the wrong .OBJDIR.
Reported by: eadler
Sponsored by: Dell EMC
Makefile.${MACHINE_ARCH} and remove the now-empty files. Generate the
*32 directories on the necessary architectures (well, currently only
amd64) on the fly. Remove LOADER_EFI variable and co-locate it with
EFI.
Differential Review: https://reviews.freebsd.org/D14546
It was originally written by Sun as part of the STF (Solaris test framework).
They open sourced it in OpenSolaris, then HighCloud partially ported it to
FreeBSD, and Spectra Logic finished the port. We also added many testcases,
fixed many broken ones, and converted them all to the ATF framework. We've had
help along the way from avg, araujo, smh, and brd.
By default most of the tests are disabled. Set the disks Kyua variable to
enable them.
Submitted by: asomers, will, justing, ken, brd, avg, araujo, smh
Sponsored by: Spectra Logic Corp, HighCloud
This code, which is basically `svnversion || svnliteversion`, generates
2 fstatat(2) for every directory in PATH for every Makefile parsed that
includes bsd.own.mk. This can add up for things like generating a Ports
index (Poudriere) or building a dependency graph for base.
Sponsored by: Dell EMC
MFC after: 2 weeks
OK. We don't really need a bsd.stand.mk, and it was causing a -fPIC
for the toolchain to be added (bogusly) when building on amd64. Pull
all relevant defs back into defs.mk and delete bsd.stand.mk.
This saves about 15-20k on i386 loader and zfsloader which when
combined with Lua give us a lot more stack space in those constrained
environments.
