Normally META_MODE ignores host files for "meta mode" decisions on whether a
file should be rebuilt or not. This is because a simple installworld can
update timestamps and cause the next build to rebuild all host tools, when the
previous ones may not have any changes in the source tree. These tools are
normally still ABI compatible. They are only rebuilt if NO_META_IGNORE_HOST is
set from the workaround/hack in r301467.
One of the major problems with this is when a host tool has objects spread
across many revisions that have mixed-ABI. For example, if struct stat were to
change on the host, some objects for a tool may have different ideas of that
struct's definition. If just 1 source file were modified and rebuilt and
linked into the tool, then that toll will have mixed-ABI objects and crash.
This exact thing happened with the ino64 commit in r301467 followed by a
trivial update to libbfd in r318750. The resulting binary would crash in
buildworld.
Sponsored by: Dell EMC Isilon
See r301467 for more details on NO_META_IGNORE_HOST. Usually the full
list of host ignores should have no real impact on the host tools. The
headers however may reliably define what the ABI is for the host. It
may be useful to allow using the headers for the build but still not
caring about things like /bin/sh, /lib/libedit.so, etc.
Sponsored by: Dell EMC Isilon
Specifically, set '-mabi=XX' in AFLAGS, CFLAGS, and LDFLAGS. This permits
building MIPS worlds and binaries with a toolchain whose default output
does not match the desired TARGET_ARCH.
_LDFLAGS (which is used with LD instead of with CC) required an update as
LD does not accept the -mabi flags (so they must be stripped from LDFLAGS
when generating _LDFLAGS). For bare uses of LD (rather than linking via
CC), the desired ABI must be set by setting an explicit linker emulation
as done in r316514 for kernels and kernel modules.
Reviewed by: imp
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D10085
Hardfloat is now default (use riscv64sf as TARGET_ARCH
for softfloat).
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8529
Running `make libfoo.ll` or `make libfoo.bc` within a library directory
will now give us an LLVM IR version of the library, and `make foo.full.ll`
or `make foo.full.bc` will give us an IR version of a binary.
As part of this change, we add an LLVM_LINK variable to sys.mk that can be
specified/overridden using an external toolchain.
Reviewed by: bdrewery, brooks
Approved by: rwatson (mentor)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8388
In r307676, several make rules were added for LLVM IR files, both in
text and binary format. Unfortunately these use different suffixes from
what upstream uses:
* Text IR has upstream suffix ".ll", while r307676 uses ".llo"
* Binary IR has upstream suffix ".bc", while r307676 uses ".bco"
Change these to what upstream uses instead.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D8326
Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).
Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.
Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.
Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.
Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.
Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683
after r307676, which added transformation rules for .llo and .bco files.
These suffixes also have to be added the the global .SUFFIXES target,
otherwise the various suffix-transformation rules would be interpreted
as literal targets. E.g.,
.c.bco:
... commands ...
would actually to build a file named ".c.bco".
As a foundation for future work with LLVM's Intermediate Representation (IR),
add new suffix rules that can be used to build .llo (text) or .bco (bitcode)
files from C or C++ sources. This compilation step uses the same CFLAGS, etc.,
as are used for building .o files, with the exception of optimization flags.
Many of the things we would like to do with IR (e.g., instrumentation) work
better with unoptimized code, so our approach is to build .c->.bco without
optimization and then apply the optimization in post-analysis,
post-instrumentation linking.
The overall result of these changes is:
* one can "make foo.llo" or "make foo.bco" wherever "make foo.o" was supported
* new make variables IR_CFLAGS and IR_CXXFLAGS are available to inspect the
flags that are used by Clang to generate the IR
These new rules are added unconditionally to our non-POSIX suffix rule set,
since we cannot inspect COMPILER_TYPE in sys.mk. Future changes that depend
on these rules (e.g., building IR versions of binaries from bsd.prog.mk)
should use COMPILER_TYPE to determine when we can expect IR rules to succeed.
Reviewed by: emaste, imp
Approved by: rwatson (mentor)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D4339
Refactor make suffix rules into separate files (one for POSIX and one not),
and rationalise the rules so that bsd.lib.mk can contain only those rules
that are library-specific (.c.po and .c.pico).
This can be accomplished by adding ${STATIC_CFLAGS} to the .c.o rule
unconditionally. STATIC_CFLAGS are only defined for use by sys.mk rules in
lib/libpam/Makefile.inc (see r227797), so it should be safe to include
them unconditionally in sys.mk's .c.o rule (tested by make universe and a
ports exp-run).
Reviewed by: bdrewery, sjg
Approved by: rwatson (mentor)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D6805
It was added to sys.mk relatively recently (r274503) for EFI builds
but is no longer used by the base system. The in-tree binutils are
outdated, will not be updated, and will be removed in the future.
Remove it from the toolchain build now to slightly simplify the build
and make sure we don't grow an accidental dependency.
Note that this affects only the toolchain build, and does not affect
/usr/bin/objdump in the built world.
Reviewed by: bdrewery
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D6460
This also adds missing s/aarch64/arm64 to the sys.mk version and also
adds back armv6hf for universe since it was added to the sys.mk version
in r300438.
MFC after: 3 days
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D7159
The DPADD data in .depend will be redundant with what is in the .meta file.
Also extend NO_EXTRADEPEND support to bsd.prog.mk.
Approved by: re (blanket, META_MODE)
Sponsored by: EMC / Isilon Storage Division
Due to META_MODE being passed into the environment it tends
to keep growing with the defaults.
Approved by: re (implicit)
Sponsored by: EMC / Isilon Storage Division
- Move the sys.mk filemon requirement to bsd.init.mk as a warning.
This is intended only to show when building directly in a subdirectory
without filemon loaded.
- Move the error into Makefile and only apply it when building
from the META_TGT_WHITELIST target list.
-DNO_FILEMON can be used to suppress both the warning and the error but
makes WITH_META_MODE less useful. It will only compare build commands
in this mode rather than track all dependencies.
This fixes installing from a jail which doesn't need filemon in this
phase [1].
Reported by: Nikolai Lifanov <lifanov@mail.lifanov.com> [1]
Approved by: re (implicit)
Sponsored by: EMC / Isilon Storage Division
Using -B already sets .MAKE.MODE=compat but it was leaving
MK_META_MODE set which could still cause other MK_META_MODE==yes
checks to trigger.
Approved by: re (implicit)
Sponsored by: EMC / Isilon Storage Division
Using buildworld, installworld, buildworld. It is expected that nothing
should rebuild. However any host tool used could have its timestamp
updated. Any library used by dynamic tools could have its timestamp
updated. The filemon(4) data in the .meta files captures all reads to
these files. This causes the 2nd buildworld to rebuild everything since
host tools and files have been updated.
Because the build is self-reliant and bootstraps itself, it should be
safe to ignore mtime changes on host files used during the build. Host
files should only impact the build of legacy, build-tools, bootstrap-tools,
cross-tools, but those are already intended to be reproducible from its
own bootstrapping. It is possible in a rare case that a bug in a host
file does produce a broken build tool. If that happens it will just
have to be communicated properly.
An alternative solution would be to update the mtime of all files in the
object directory after installworld so that the host files are not newer
than the object files. That also requires special care for read-only
obj directories and special care to not mess with any intended timestamps in
the build, such as done for reproducibility.
Reported by: many
Sponsored by: EMC / Isilon Storage Division
This breaks cross-building with WITH_META_MODE since it will rebuild
'build-tools' during the 'everything' phase.
A more proper fix is coming to bmake to implicitly require .META unless
.NOMETA (and other restrictions) are in place.
Since META_MODE is being sold and used as a working incremental build, it won't
make much sense if filemon data is excluded. There is no way to recover
from that in a subsequent build.
Sponsored by: EMC / Isilon Storage Division
Adding .META to targets-to-build will ensure that they will rebuild if there
is no .meta file.
Adding it to all SUFFIXES and objects ensures that at least objects will
rebuild if there is no .meta file.
This will be reverted if bmake's behavior changes to rebuild on missing .meta
files.
Sponsored by: EMC / Isilon Storage Division
It turns out we need to leave this in place for a while so that people
running self-hosting armv6hf systems can do the builds necessary to update
to armv6 (which is now hardfloat by default).
This will ensure that the variable was not set as a make override, in
make.conf, src.conf or src-env.conf. It allows setting the value in
src-env.conf when using WITH_AUTO_OBJ since that case properly handles
changing .OBJDIR (except if MAKEOBJDIRPREFIX does not yet exist which is
being discussed to be changed).
This change allows setting a default MAKEOBJDIRPREFIX via local.sys.env.mk.
Sponsored by: EMC / Isilon Storage Division
RISC-V is a new ISA designed to support computer research and education, and
is now become a standard open architecture for industry implementations.
This is a minimal set of changes required to run 'make kernel-toolchain'
using external (GNU) toolchain.
The FreeBSD/RISC-V project home: https://wiki.freebsd.org/riscv.
Reviewed by: andrew, bdrewery, emaste, imp
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D4445
Tracking these leads to situations where meta mode will consider the
file to be out of date if /bin/sh or /bin/ln are newer than the source
file. There's no reason for meta mode to do this as make is already
handling the rebuild dependency fine.
Sponsored by: EMC / Isilon Storage Division
This has caused much confusion for myself as there are quite a lot of
variables that depend on having a proper ${.OBJDIR}.
Sponsored by: EMC / Isilon Storage Division
This allows most of the build to simply consider MK_META_MODE
Update to latest dirdeps.mk so we can do:
make -f dirdeps.mk bin/cat.i386
Reviewed by: bdrewery
This allows META_FILES option to be renamed META_MODE.
Also add META_COOKIE_TOUCH for use in targets that can benefit
from a cookie when in meta mode.
Differential Revision: https://reviews.freebsd.org/D4153
Reviewed by: bdrewery
ccache is mostly beneficial for frequent builds where -DNO_CLEAN is not
used to achieve a safe pseudo-incremental build. This is explained in
more detail upstream [1] [2]. It incurs about a 20%-28% hit to populate the
cache, but with a full cache saves 30-50% in build times. When combined with
the WITH_FAST_DEPEND feature it saves up to 65% since ccache does cache the
resulting dependency file, which it does not do when using mkdep(1)/'CC
-E'. Stats are provided at the end of this message.
This removes the need to modify /etc/make.conf with the CC:= and CXX:=
lines which conflicted with external compiler support [3] (causing the
bootstrap compiler to not be built which lead to obscure failures [4]),
incorrectly invoked ccache in various stages, required CCACHE_CPP2 to avoid
Clang errors with parenthesis, and did not work with META_MODE.
The option name was picked to match the existing option in ports. This
feature is available for both in-src and out-of-src builds that use
/usr/share/mk.
Linking, assembly compiles, and pre-processing avoid using ccache since it is
only overhead. ccache does nothing special in these modes, although there is
no harm in calling it for them.
CCACHE_COMPILERCHECK is set to 'content' when using the in-tree bootstrap
compiler to hash the content of the compiler binary to determine if it
should be a cache miss. For external compilers the 'mtime' option is used
as it is more efficient and likely to be correct. Future work may optimize the
'content' check using the same checks as whether a bootstrap compiler is needed
to be built.
The CCACHE_CPP2 pessimization is currently default in our devel/ccache
port due to Clang requiring it. Clang's -Wparentheses-equality,
-Wtautological-compare, and -Wself-assign warnings do not mix well with
compiling already-pre-processed code that may have expanded macros that
trigger the warnings. GCC has so far not had this issue so it is allowed to
disable the CCACHE_CPP2 default in our port.
Sharing a cache between multiple checkouts, or systems, is explained in
the ccache manual. Sharing a cache over NFS would likely not be worth
it, but syncing cache directories between systems may be useful for an
organization. There is also a memcached backend available [5]. Due to using
an object directory outside of the source directory though you will need to
ensure that both are in the same prefix and all users use the same layout. A
possible working layout is as follows:
Source: /some/prefix/src1
Source: /some/prefix/src2
Source: /some/prefix/src3
Objdir: /some/prefix/obj
Environment: CCACHE_BASEDIR='${SRCTOP:H}' MAKEOBJDIRPREFIX='${SRCTOP:H}/obj'
This will use src*/../obj as the MAKEOBJDIRPREFIX and tells ccache to replace
all absolute paths to be relative. Using something like this is required due
to -I and -o flags containing both SRC and OBJDIR absolute paths that ccache
adds into its hash for the object without CCACHE_BASEDIR.
distcc can be hooked into by setting CCACHE_PREFIX=/usr/local/bin/distcc.
I have not personally tested this and assume it will not mix well with
using the bootstrap compiler.
The cache from buildworld can be reused in a subdir by first running
'make buildenv' (from r290424).
Note that the cache is currently different depending on whether -j is
used or not due to ccache enabling -fdiagnostics-color automatically if
stderr is a TTY, which bmake only does if not using -j.
The system I used for testing was:
WITNESS
Build options: -j20 WITH_LLDB=yes WITH_DEBUG_FILES=yes WITH_CCACHE_BUILD=yes
DISK: ZFS 3-way mirror with very slow disks using SSD l2arc/log.
The arc was fully populated with src tree files and ccache objects.
RAM: 76GiB
CPU: Intel(R) Xeon(R) CPU L5520 @2.27GHz
2 package(s) x 4 core(s) x 2 SMT threads = hw.ncpu=16
The WITH_FAST_DEPEND feature was used for comparison here as well to show
the dramatic time savings with a full cache.
buildworld:
x buildworld-before
+ buildworld-ccache-empty
* buildworld-ccache-full
% buildworld-ccache-full-fastdep
# buildworld-fastdep
+-------------------------------------------------------------------------------+
|% * # +|
|% * # +|
|% * # xxx +|
| |A |
| A|
| A |
|A |
| A |
+-------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 3 3744.13 3794.31 3752.25 3763.5633 26.935139
+ 3 4519 4525.04 4520.73 4521.59 3.1104823
Difference at 95.0% confidence
758.027 +/- 43.4565
20.1412% +/- 1.15466%
(Student's t, pooled s = 19.1726)
* 3 1823.08 1827.2 1825.62 1825.3 2.0785572
Difference at 95.0% confidence
-1938.26 +/- 43.298
-51.5007% +/- 1.15045%
(Student's t, pooled s = 19.1026)
% 3 1266.96 1279.37 1270.47 1272.2667 6.3971113
Difference at 95.0% confidence
-2491.3 +/- 44.3704
-66.1952% +/- 1.17895%
(Student's t, pooled s = 19.5758)
# 3 3153.34 3155.16 3154.2 3154.2333 0.91045776
Difference at 95.0% confidence
-609.33 +/- 43.1943
-16.1902% +/- 1.1477%
(Student's t, pooled s = 19.0569)
buildkernel:
x buildkernel-before
+ buildkernel-ccache-empty
* buildkernel-ccache-empty-fastdep
% buildkernel-ccache-full
# buildkernel-ccache-full-fastdep
@ buildkernel-fastdep
+-------------------------------------------------------------------------------+
|# @ % * |
|# @ % * x + |
|# @ % * xx ++|
| MA |
| MA|
| A |
| A |
|A |
| A |
+-------------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 3 571.57 573.94 571.79 572.43333 1.3094401
+ 3 727.97 731.91 728.06 729.31333 2.2492295
Difference at 95.0% confidence
156.88 +/- 4.17129
27.4058% +/- 0.728695%
(Student's t, pooled s = 1.84034)
* 3 527.1 528.29 528.08 527.82333 0.63516402
Difference at 95.0% confidence
-44.61 +/- 2.33254
-7.79305% +/- 0.407478%
(Student's t, pooled s = 1.02909)
% 3 400.4 401.05 400.62 400.69 0.3306055
Difference at 95.0% confidence
-171.743 +/- 2.16453
-30.0023% +/- 0.378128%
(Student's t, pooled s = 0.954969)
# 3 201.94 203.34 202.28 202.52 0.73020545
Difference at 95.0% confidence
-369.913 +/- 2.40293
-64.6212% +/- 0.419774%
(Student's t, pooled s = 1.06015)
@ 3 369.12 370.57 369.3 369.66333 0.79033748
Difference at 95.0% confidence
-202.77 +/- 2.45131
-35.4225% +/- 0.428227%
(Student's t, pooled s = 1.0815)
[1] https://ccache.samba.org/performance.html
[2] http://www.mail-archive.com/ccache@lists.samba.org/msg00576.html
[3] https://reviews.freebsd.org/D3484
[5] https://github.com/jrosdahl/ccache/pull/30
PR: 182944 [4]
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
Relnotes: yes
Bmake has a documented feature of '-N' to skip executing commands which is
specifically intended for debugging top-level builds and not recursing into
sub-directories. This matches the older 'make -n' behavior we added which made
'-n -n' the recursing target and '-n' a non-recursing target.
Removing the '-n -n' feature allows the build to work as documented in
the bmake manpage with '-n' and '-N'. The older '-n -n' feature was also
not documented anywhere that I could see.
Note that the ${_+_} var is still needed as currently bmake incorrectly
executes '+' commands when '-N' is specified.
The '-n' and '-n -n' features were broken for several reasons prior to this.
r251748 made '_+_' never expand with '-n -n' which resulted in many
sub-directories not being visited until fixed 2 years later in r288391, and
many targets were given .MAKE over the past few years which resulted in
non-sub-make commands, such as rm and ln and mtree, to be executed.
This should also allow removing some indirection hacks in bsd.subdir.mk and
other cases of .USE that have a .MAKE by using '+'.
Sponsored by: EMC / Isilon Storage Division
Discussed on: arch@ (mostly silence)
This is a NOP as r254419 enabled this by default in bmake. Add it here though
to ensure it is known that we are using this as a default and in case a
bmake import removes the default we have.
This tells bmake to always pass job tokens into sub-commands. Otherwise
it would only do so if the target being built depended on the special
.MAKE target (which causes _all_ commands to be executed with -n as well)
or if the command matches '${MAKE}/${.MAKE}/$(MAKE)/$(.MAKE)/make' (before
expansion, so ${LIB32WMAKE} would not qualify). Using '+' on a command
(which runs the command with -n) would not pass the job token even though it
is a documented way to achieve the .MAKE effect on a command.
Sponsored by: EMC / Isilon Storage Division
