Until clang 11 that was equivalent to -O2, but clang changed it to -O1 so
generated MIPS code will now be unnecessarily slow. It also removes a weird
special case from sys.mk.
This is similar to the D26471 change for debug kernels and should not change
anything since everything was previously building MIPS code at -O2 until the
clang 11 update.
Reviewed By: trasz
Differential Revision: https://reviews.freebsd.org/D26749
This is the initial set up for PowerPC64LE.
The current plan is for this arch to remain experimental for FreeBSD 13.
This started as a weekend learning project for me and kinda snowballed from
there.
(More to follow momentarily.)
Reviewed by: imp (earlier version), emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26399
Use of ranlib or lorder is no longer necessary with current linkers
(probably anything newer than ~1990) and ar's ability to create an object
index and symbol table in the archive.
Currently the build system uses lorder+tsort to sort the .o files in
dependency order so that a single-pass linker can use them. However,
we can use the -s flag to ar to add an index to the .a file which makes
lorder unnecessary.
Running ar -s is equivalent to running ranlib afterwards, so we can also
skip the ranlib invocation.
Similarly, we don't have to pass the .o files for shared libraries in
dependency order since both ld.bfd and ld.lld will correctly resolve
references between the .o files.
This removes many fork()+execve calls for each library so should speed up
builds a bit. Additionally lorder.sh uses a regular expression that is not
supported by the macOS libc or glibc and results in many warnings when
cross-building (see D25989).
There is one functional change: lorder.sh removed duplicated .o files
from the linker command line which now no longer happens. I fixed the duplicates
in the base system in r364649. I also checked the ports tree for uses of
bsd.lib.mk and found one duplicate source file which I fixed in r548168.
Most ports use CMake/autotools rather than bsd.lib.mk but if this breaks any
ports that I missed in my search please let me know.
Avoiding the shell script actually speeds up the linking step noticeably: I
measured how long it takes to rebuild the .a and .so files for lib/libc using a
basic benchmark: `rm $LIBC_OBJDIR/*.so* $LIBC_OBJDIR/*.a* && /usr/bin/time make -DWITHOUT_TESTS -s > /dev/null`
Without this change ~4.5 seconds and afterwards ~3.1 seconds.
Looking at truss -cf output we can see that the number fork() system
calls goes down from 27 to 12 (and the speedup while tracing is more
noticeable: 81 seconds -> 65 seconds).
See also https://www.gnu.org/software/coreutils/manual/html_node/tsort-background.html
for some more background:
This whole procedure has been obsolete since about 1980, because Unix
archives now contain a symbol table (traditionally built by ranlib, now
generally built by ar itself), and the Unix linker uses the symbol table
to effectively make multiple passes over an archive file.
Or alternatively https://www.unix.com/man-page/osf1/1/lorder/:
The lorder command is essentially obsolete. Use the following command in
its place: % ar -ts file.a
Reviewed By: emaste, imp, dim
Differential Revision: https://reviews.freebsd.org/D26044
Since the make variable STRIP is already used for other purposes, this
uses STRIPBIN (which is also used for the same purpose by install(1).
This allows using LLVM objcopy to strip binaries instead of the in-tree
elftoolchain objcopy. We make use of this in CheriBSD since passing
binaries generated by our toolchain to elftoolchain strip sometimes results
in assertion failures.
This allows working around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248516
by specifying STRIPBIN=/path/to/llvm-strip
Obtained from: CheriBSD
Reviewed By: emaste, brooks
Differential Revision: https://reviews.freebsd.org/D25988
instead of sprinkling them out over many disjoint files. This is a follow-up
to achieve the same goal in an incomplete rev.348521.
Approved by: imp
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D20520
The -fuse-ld flag is only meant to be passed to the compiler driver so
direct linker invocations should not include it.
Reviewed by: emaste, jhb
Approved by: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D12910
Despite the fact that it's a working solution, it doesn't follow the design
philosophy of only doing TARGET_* in Makefile.inc1 and special locations in
the source tree.
PR: 222925
Requested by: imp
Forcing MK_AUTO_OBJ to no is not really needed since bsd.obj.mk is protected
against 'rm -rf ${.CURDIR}' already. It was also flawed as if MK_AUTO_OBJ=yes
was in the .MAKEOVERRIDES already then it just remained on.
Sponsored by: Dell EMC Isilon
This is to prevent downstream checks from assuming they can trust .OBJDIR when
MK_AUTO_OBJ is yes, such as the bsd.obj.mk checks.
Pointyhat to: bdrewery
Sponsored by: Dell EMC Isilon
This can be disabled by putting WITHOUT_AUTO_OBJ=yes in /etc/src-env.conf, not
/etc/src.conf, or passing it in the environment.
The purpose of this rather than simply flipping the default of AUTO_OBJ to yes
is to avoid hassling users with auto.obj.mk failures if the wanted OBJDIR is
not writable. It will fallback to writing to the source directory like it does
today if MAKEOBJDIRPREFIX is not writable.
The act of enabling MK_AUTO_OBJ disables all 'make obj' treewalks since
previous work has made those not run if MK_AUTO_OBJ==yes in Makefile.inc1.
Relnotes: yes
Reviewed by: sjg
Discussed at: https://lists.freebsd.org/pipermail/freebsd-arch/2016-May/017805.html
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12841
This changes the build OBJDIR from the older style of /usr/obj/<srcdir> for
native builds, and /usr/obj/<target>.<target_arch>/<srcdir> for cross builds to
a new simpler format of /usr/obj/<srcdir>/<target>.<target_arch>. This
new format is used regardless of cross or native build. It allows
easier management of multiple source tree object directories.
The UNIFIED_OBJDIR option will be removed and its feature made permanent
for the 12.0 release.
Relnotes: yes (don't note UNIFIED_OBJDIR option since it will be removed)
Prior work: D3711 D874
Reviewed by: gjb, sjg
Discussed at: https://lists.freebsd.org/pipermail/freebsd-arch/2016-May/017805.html
Discussed with: emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12840
When cross-compiling, the wrong architecture was being embedded in the
libclang_rt binary filenames. It should be based on TARGET_ARCH (target), not
MACHINE_ARCH (host).
This is a draft commit against my project branch. Will fix on ^/head soon.
PR: 222925
Make armv7 as a new MACHINE_ARCH.
Copy all the places we do armv6 and add armv7 as basically an
alias. clang appears to generate code for armv7 by default. armv7 hard
float isn't supported by the the in-tree gcc, so it hasn't been
updated to have a new default.
Support armv7 as a new valid MACHINE_ARCH (and by extension
TARGET_ARCH).
Add armv7 to the universe build.
Differential Revision: https://reviews.freebsd.org/D12010
Consolidate all the regular expressions to convert from MACHINE_ARCH
to MACHINE_CPUARCH into a variable and use that variable in preference
to the almost identical copies in the tree (which should have been
identical).
Differential Revision: https://reviews.freebsd.org/D11986
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
