the oabi is still in the tree, but it is expected this will be removed
as developers work on surrounding code.
With this commit the ARM EABI is the only supported supported ABI by
FreeBSD on ARMa 32-bit processors.
X-MFC after: never
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D876
ARM EABI support is disabled by default and can be enabled by setting
WITH_ARM_EABI when building, however only the kernel-toolchain target will
work with this flag until the rest of the support is added.
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>
It was used mainly to discover and fix some 64-bit portability problems
before 64-bit arches were widely available.
Discussed with: bde
Approved by: kib (mentor)
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.
TARGET_BIG_ENDIAN is now completely dead, except where it was
originally supposed to be used (internally in the toolchain building).
TARGET_ARCH has changed in three cases:
(1) Little endian mips has changed to mipsel.
(2) Big endian mips has changed to mipseb.
(3) Big endian arm has changed to armeb.
Some additional changes are needed to make 'make universe' work on arm
and mips after this change, so those are commented out for now.
UPDATING information will be forthcoming. Any remaining rough edges
will be hammered out in -current.
MIPS-III because FreeBSD relies on a number of MIPS-III features; the ABI
default would be MIPS-I which we don't intend to support. Our old default
before I switched to using the ABI default was MIPS32.
o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default
ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is
the current default.
o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is
necessary to have a working "cc" if e.g. mips64 is specified, as binutils
will refuse to link objects using different ISAs in some cases.
o) Add support for n32 and n64 ABIs to binutils and GCC.
o) Add additional required libgcc2 stubs for n32 and n64.
o) Add support for the "mips64r2" architecture to GCC. Add the "octeon"
o) When static linking, wrap default libraries in --start-group and
--end-group. This is required for static linking to work on n64 with the
interdependencies between libraries there. This is what other OSes that
support n64 seem to do, as well.
o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the
former being what libgcc, etc., check and the latter seemingly being a
misspelling of a hand merge from a Linux spec.
o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default
ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit
ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to
the MIPS32 ISA, when we are supporting or will support some systems based on
earlier 32-bit and 64-bit ISAs, most notably MIPS-III.
o) Merge a new opcode file (and support code) from a later version of binutils
and add flags and code necessary to support Octeon-specific instructions.
This should also make merging opcodes for other modern architectures easier.
Reviewed by: imp
In particular, vendor sources that aren't ready for gnu99 should
still be compiled with gnu89. (Before r189824, these would have
generated warnings if you tried to compile them in gnu99 mode,
but the warnings went unheeded due to -Wno-error.)
Also:
Switch FreeBSD to use libgcc_s.so.1.
Use dl_iterate_phdr to locate shared objects' exception frame
info instead of depending on older register_frame_info machinery.
This allows us to avoid depending on libgcc_s.so.1 in binaries
that do not use exception handling directly. As an additional
benefit it breaks circular libc <=> libgcc_s.so.1 dependency too.
Build newly added libgomp.so.1 library, the runtime support
bits for OpenMP.
Build LGPLed libssp library. Our libc provides our own
BSD-licensed SSP callbacks implementation, so this library
is only built to benefit applications that have hadcoded
knowledge of libssp.so and libssp_nonshared.a. When linked
in from command line, these libraries override libc
implementation.
'target'. Latter is problematic in particular as apparently FreeBSD's
bsd.prog.mk re-defines it under some circumstances. This causes an
unexpected failures like -dumpmachine not working for cc while working
fine for c++.
Do not re-define IN_GCC in multipe places, it gets inherited from
Makefile.in anyway.
PR: gnu/110143
Submitted by: usleepless at gmail
value, it forces GCC to not optimize above this level. For intance, GCC
made with "WANT_FORCE_OPTIMIZATION_DOWNGRADE=1" is a good setting for the
Alpha platform when building ports.
of stuff (and thus length of error output) we put on the invocation command
line. Also follow the new FSF/GNU style of giving the symbol a value so it
can be used in `if()' statements in addition to `#if' so seldomly compiled
in code (on some platforms) gets compiled always, to help reduce bit-rot.
If one wishes to anchor the compiler toolchain tree somewhere other than /,
all one needs to do is set "TOOLS_PREFIX" to a different rooting.
Submitted by: marcel (in a different format and reworked by me)
When I imported EGCS into contrib/egcs/ I failed to prune out
egcs/gcc/cp/hash.h which is generated from gxx.gperf. Thus `cc1plus' wasn't
using the hash.h we generated by cc/cc_tools/Makefile, but rather the one in
egcs/gcc/cp/.
When I imported contrib/gcc/ I did prune gcc/cp/hash.h. Unfortunately the
GCC maintainers weren't smart on their file nameing and there is also a
egcs/gcc/hash.h (name overloading does NOT work as well on the filesystem
as in C++...). Due to the -I ordering we are were then picking up gcc/hash.h
when compiling `cc1plus'.
