because they pollute the POSIX environment, which doens't allow
for these extentions. ctf conversions are really only relevant when
used in coordination with the rest of the bsd*.mk system anyway.
Leave them in place for the normal, non-posix enviornment since
they are quite useful there.
all timestamps in static libraries to 0 so that consecutive builds
from the same source, even on different machines, produce identical
libraries.
MFC after: 3 weeks
This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.
armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX
In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC
As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.
But we don't want to set it to + for bmake since it breaks make -N
which is used to supress the normal handling of targets marked with .MAKE
(which seems broken in fmake and might be why _+_ was introduced).
Add some comments to explain what's gong on.
Reviewed by: obrien
1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE,
there's a bootstrap complication in ths respect. Avoid it. Make the
necessary changes to have upgrade_checks work wth bmake anyway.
2. Remove the use of -E. It's not needed in our build because we use ?= for
the respective variables, which means that we'll take the environment
value (if any) anyway.
3. Properly declare phony targets as phony as bmake is a lot smarter (and
thus agressive) about build avoidance.
4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot
smarter about build avoidance and should not find files we generate in
the source tree. We should not have files in the repository we want to
generate, but this is an easier way to cross this hurdle.
5. Have behavior under bmake the same as it is under make with respect to
halting when sub-commands fail. Add "set -e" to compound commands so
that bmake is informed when sub-commands fail.
6. Make sure crunchgen uses the same make as the rest of the build. This
is important when the make utility isn't called make (but bmake for
example).
7. While here, add support for using MAKEOBJDIR to set the object tree
location. It's the second alternative bmake looks for when determining
the actual object directory (= .OBJDIR).
Submitted by: Simon Gerraty <sjg@juniper.net>
Submitted by: John Van Horne <jvanhorne@juniper.net>
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS builds which are little-endian
should require and exhibit no changes. Big-endian TARGET_ARCHes must be
changed:
From: To:
mipseb mips
mipsn32eb mipsn32
mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete
with warnings which should become errors in the near future) to the top-level
base system Makefile.
- CTFCONVERT_CMD=... is a hack (should be defined to empty string instead):
make(1) should be taught to ignore empty commands silently in compat mode
(as it does in !compat mode, GNU make also silently ignores empty commands)
and to skip printing empty commands in !compat mode
- config(8) should generate ${NORMAL_CTFCONVERT} invocation without '@':
this will allow to simplify kern.pre.mk even more and lessen the number
of shell invocations during kernel build when CTF is turned off
- WITH_CTF can now be converted to usual MK_CTF=yes/no infrastructure
Pointy hat to: fjoe [1]
Implement MACHINE_ARCH=mips64e[lb] to build N64 images. This replaces
MACHINE_ARCH=mipse[lb] TARGET_ABI=n64.
MACHINE_ARCH=mipsn32e[lb] has been added, but currently requires
WITHOUT_CDDL due to atomic issues in libzfs. I've not investigated
this much, but implemented this to preserve as much of the TARGET_ABI
functionality that I could. Since its presence doesn't affect the
working cases, I've kept it in for now.
Added mips64e[lb] to make universe, so more kernels build.
And I think this (finally) closes the curtain on the tbemd tree.
run. This makes the 'ctfconvert' and 'ctfmerge' programs show up during
a build when compiling a kernel, a library or a program.
Sponsored by: The FreeBSD Foundation
Introduce MACHINE_CPUARCH. Many different MACHINE_ARCHs will be built
from one MACHINE_CPUARCH. This will allow us to move to a more
standard MACHINE_ARCH for mips and arm which exist in many different
endian variants, and for powerpc where both 32 and 64 bit binaries are
generated from the same sources.
Reviewed by: arch@ (mostly silence though)
are some problems with static executables), make.conf (would also
affect ports which do not use GNU make and do not override the
compile targets) or in the kernel config (via "makeoptions
WITH_CTF=yes").
Additional (related) changes:
- propagate WITH_CTF to module builds
- do not add -g to the linker flags, it's a noop there anyway
(at least according to the man page of ld)
- do not add -g to CFLAGS unconditionally
we need to have a look if it is really needed (IMO not) or if there
is a way to add it only when WITH_CTF is used
Note: ctfconvert / ctfmerge lines will not appear in the build output,
to protect the innocent (those which do not build with WITH_CTF would
see the shell-test and may think WITH_CTF is used).
Reviewed by: imp, jhb, scottl (earlier version)
Discussed on: arch@
system makefiles.
Note that the CTF conversion defaults to off. We may choose to change this
default later if DTrace proves popular and people are prepared to wear
the compilation performance impact of compiling with debug symbols all the
time.
Setting NO_CTF in the make args or user environment turns off CTF conversion.
Even if we choose to default CTF generation to on later, we still need
NO_CTF so that the buildworld process can bootstrap the tools without
needlessly generating CTF data for temporary tools.
Setting WITH_CTF in the make args or user environment (and _NOT_ in
/etc/make.conf) is the only way to enable CTF data conversion. Nore that
this can't be implemented the same way that the WITH_ and WITHOUT_ stuff
is implemented throughout the buildworld because the CTF conversion needs
to work when building a simple object without a Makefile, using the
default rules in sys.mk.
Typing 'make test.o' with no makefile and just a source file test.c
should work. Also, typing 'make WITH_CTF=1 test.o without a makefile and
just a source file test.c should work and produce an object with a CTF
elf section. Typing 'make WITH_CTF=1 CFLAGS=-g test.o' without a makefile
and just a source file test.c should produce an object with both a CTF
elf section and the debug elf sections.
In the FreeBSD build where more .mk files are used than just sys.mk
which is included my make by default, the use of DEBUG_FLAGS is the
correct way to enable a debug build. The important thing to note here
is that it is the DEBUG_FLAGS setting that prevents libraries and
programs from being stripped on installation. So, for the addition of
CTF data conversion, setting DEBUG_FLAGS to contain -g, without NO_CTF,
will cause the ctfconvert and ctfmerge build programs to be executed
also with the -g arg so that debug symbols are retained rather than
being removed after the CTF data elf section has been added.
Add DTrace libraries to the list of libnames.
o Default to -O on mips as well as arm. -O2 has been strongly implicated
in many problems in the past, so we're taking a conservative approach
until the problems are well understood.
to JB's revision 1.96 change to remove -fno-strict-aliasing from CFLAGS.
This makes the default CFLAGS to match the simple defaults that the
tinderboxes use. By using -fno-strict-aliasing by default we are
choosing to ignore problems in code which had the potential to
shoot ourselves in the foot.
address PR ports/121363 (current day re-opening of PR ports/73797)
to make ports CFLAGS more independent of src/'s CFLAGS WRT aliasing.
Discussed with: brooks
Change the default CFLAGS to match the simple defaults that the
tinderboxes use. By using -fno-strict-aliasing by default we are
choosing to ignore problems in code which had the potential to
shoot ourselves in the foot.
in the default CFLAGS, we're in the middle of a ports freeze, so we can't
really go making the corresponding change to the ports mk files.
I'll take -fno-strict-aliasing out again when the ports freeze ends.
This time, change the default CFLAGS to match the simple defaults that
the tinderboxes use. That is, don't use -fno-strict-aliasing by default.
My last attempt to re-anable -Werror gave me a lesson in what strict
aliasing is all about. There was code in libthr that wasn't 64-bit clean.
The default use of -fno-strict-aliasing hid that.
By using -fno-strict-aliasing by default we were choosing to ignore
problems in code which had the potential to shoot ourselves in the
foot. Sometimes it would be the 64-bit foot. I have both feet. The left
ones are 32 bits and the right ones are 64 bits. Don't ask about my
endian orientation. :-)
The -fno-strict-aliasing compiler arg can still be used if NO_STRING_ALIASING
is define in make.
We are early in the FreeBSD 8 development, so we have the opportunity to
wait and see if this works for us. I am sure that people will complain.
We can easily revert this. All I ask is that we take sides: clean code or
not. YMMV.
Note that by using -fno-strict-aliasing the build won't actually break.
Only where WARNS is set (and -Werror is used) will a compiler warning break
the build. The use of WARNS levels implies (to me at least) that the
developer has taken some care to make the code pass basic checks. This
commit makes those checks just a little bit more strict.
__MAKE_SHELL variable. This feature isn't supposed to be in wide
use, but it's needed now to make `installworld' independent of the
stock binaries and libs so that radical ABI changes can go in safely.
Reviewed by: ru
"There seems to be some continuing discussion about how this is best fixed,
and we'd like to get Alexander (as our gcc guru) to opine on a final
solution before picking one. In the mean time, could you back out the
original commit (sys.mk:1.89)?"
Approved by: re (rwatson)
