This change allows any downstream or otherwise consumer to easily override
the new -fno-common default on a temporary basis without having to hack into
src.sys.mk, and also makes it a bit easier to search for these specific
cases where -fno-common must be overridden with -fcommon or else the build
will fail.
The gdb build, the only program requiring -fcommon on head/, is switched
over as an example usage. It will need it on all branches, so this does not
harm future mergability.
MFC after: 3 days
In-tree gdb is essentially obsolete. We kept it for sparc64 (because
gdb in ports lacked sparc64 support) and as a fallback for crashinfo.
gdb was installed to /libexec on all archs other than sparc64, where the
WITHOUT_GDB_LIBEXEC option was default, with gdb installed to /usr/bin.
With sparc64's retirement WITH_GDB_LIBEXEC became the default for all
architectures, but it was still possible to set it off and install gdb
into /usr/bin.
As the next step in gdb's retirement, remove the option and install gdb
only into /libexec as the crashinfo fallback. We expect users to install
the gdb port or package for debugging. The in-tree gdb lacks support for
a number of supported architectures and does not support contemporary
DWARF debug info.
Reviewed by: jhb (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24227
As described in the comment, gdb relies on some of the linker magic that
happens with -fcommon. I suspect the life expectancy of gdb-in-base is low
enough that this isn't worth spending much time addressing, especially given
the vintage. Hit it with the -fcommon hammer so that it continues to just
work.
MFC after: 3 days
Now that LLD 10 is out, and required patches have landed, we are now ready
to finally switch away from the ancient in-tree ld.bfd.
Special thanks to Fangrui Song for many hours of work on getting the
32-bit powerpc lld ready for prime-time.
Reviewed by: emaste (earlier revision), jhibbits
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D24111
Now that we no longer have GCC 4.2.1 in the tree and can assume FreeBSD
is being built with a C++11 compiler available, we can use BSDL dtc
unconditionally and retire the GPL dtc.
GPL dtc now has FreeBSD CI support via Cirrus-CI to help ensure it
continues to build/work on FreeBSD and is available in the ports tree
if needed.
The copy of (copyfree licensed) libfdt that we actually use is in
sys/contrib/libfdt so the extra copy under contrib/dtc/libfdt can be
removed along with the rest of the GPL dtc.
Reviewed by: kevans, ian, imp, manu, theraven
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23192
As described in Warner's email message[1] to the FreeBSD-arch mailing
list we have reached GCC 4.2.1's retirement date. At this time all
supported architectures either use in-tree Clang, or rely on external
toolchain (i.e., a contemporary GCC version from ports).
GCC 4.2.1 was released July 18, 2007 and was imported into FreeBSD later
that year, in r171825. GCC has served us well, but version 4.2.1 is
obsolete and not used by default on any architecture in FreeBSD. It
does not support modern C and does not support arm64 or RISC-V.
Thanks to everyone responsible for maintaining, updating, and testing
GCC in the FreeBSD base system over the years.
So long, and thanks for all the fish.
[1] https://lists.freebsd.org/pipermail/freebsd-arch/2020-January/019823.html
PR: 228919
Reviewed by: brooks, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23124
GNU as 2.17.50 is currently required by amd64 and i386 for at least one
file that cannot be assembled by Clang's integrated assembler (IAS).
Other supported CPU architectures either use Clang IAS for all assembly
files, or rely on external toolchain.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23180
All archs except powerpc either use lld or require external toolchain.
powerpc still needs binutils ld to link 32-bit binaries.
Reviewed by: jhibbits
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23107
As of r356514 LLVM's libunwind is used as the DWARF unwinder on all
supported CPU architectures, and GCC and its libraries will be removed
soon. Retire the build infrastructure for GCC's unwinder; from here
if there are any unwinder bugs (on any arch) the path forward is to fix
LLVM's libunwind.
r356356 started providing libssp based on ^/lib/libc/secure and disconnected
this version from the build. This one did formally provide runtime support
for _FORTIFY_SOURCE, but FreeBSD lacks the build support that would have
been needed to take advantage of it.
MFC after: never
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.
PR: 242950 (exp-run)
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
Also discussed with: kan
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22943
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
gets is unsafe and shouldn't be used (for many years now). Leave it in
the existing symbol version so anything that previously linked aginst it
still runs, but do not allow new software to link against it.
(The compatability/legacy implementation must not be static so that
the symbol and in particular the compat sym gets@FBSD_1.0 make it
into libc.)
PR: 222796 (exp-run)
Reported by: Paul Vixie
Reviewed by: allanjude, cy, eadler, gnn, jhb, kib, ngie (some earlier)
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12298
In the future FreeBSD will ship without GNU binutils 2.17.50. Add a
note advising users who require GNU as to install the binutils port
or package.
Note that on armv7, arm64, amd64, i386 we currently ship only two
binutils tools (as and objdump). A deprecation notice was added to
objdump's man page some time ago.
PR: 233611
Discussed with: jhb
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
We may install llvm-objdump as objdump (see review D18307) or just
provide no /usr/bin/objdump, but either way GNU objdump won't be
installed in the future.
MFC after: 3 days
r335217 added a deprecation notice to the source file for the objdump
man page, and r335219 added it to the rendered objdump.1, but in the
wrong spot.
MFC after: 3 days
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 doesn't appear to have ever worked. After a .depend is generated
there will be duplicate .c dependencies so only use the first one.
MFC after: 2 weeks
Sponsored by: DellEMC
This is for an upcoming change that fixes .depend handling in here.
It will cause some duplicate sources which need to be trimmed out.
MFC after: 2 weeks
Sponsored by: DellEMC
When using LLVM+clang+lld on PowerPC64, ld.bfd is also needed,
to link 32-bit binaries correctly, as lld support for 32-bit is
still minimal.
This change enables it to be built and installed when lld is used.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D20259
* 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 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
Summary:
GCC expects to link in a crtsavres.o on powerpc platforms. On
powerpc64 this is an empty file, but on powerpc and powerpcspe this does contain
some save/restore functions, which may not actually be necessary for newer
modern GCC and clang. This appeases the in-tree gcc, though, and is needed in
order to switch to the BSD CRTRBEGIN.
PR: 233751
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D18826
Without this change I get lots of
warning: duplicate script for target "_FILESINS_ldscripts/elf64btsmip_fbsd.xw" ignored
message for every tree walk.
Reviewed By: imp, emaste
Differential Revision: https://reviews.freebsd.org/D18783
GNU binutils ld.bfd 2.17.50 does not support ifuncs and produces broken
binaries when ifuncs are in use. When LLD_IS_LD is default we have an
ifunc-capable system linker and can just avoid installing ld.bfd.
Reported by: theraven
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18340
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
We're studing the possibility of deprecating sbrk(). To make it easier
we're removing unnecessicary uses in the base system. None of these
tools require sbrk(), but they agressively prefer it for no good reason.
Reviewed by: andrew
Approved by: re (kib)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16141
Its been quite a while since the last time we updated this and since then
we have grown iconv and a bunch of complex math functions.
This only applies to the platforms which still use GCC 4.2.1 in the
toolchain.
Differential Revision: https://reviews.freebsd.org/D16289
- Change the C++ directory entries to honor --sysroot if it is set.
- Don't define CROSS_INCLUDE_DIR for the cross compiler. Instead, set
TARGET_SYSTEM_ROOT to point to WORLDTMP and always define
STANDARD_INCLUDE_DIR.
- Change STANDARD_INCLUDE_DIR and the C++ include directories to just
start with "/usr" always. The compiler will prepend the sysroot when
doing cross-builds. GCC_INCLUDE_DIR (which contains headers that ship
with the compiler such as intrinsincs rather than OS-supplied headers)
remains hardcoded to look in TOOLS_PREFIX.
Reviewed by: bdrewery (older version)
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D15127
GCC 4.2 prefixes these directories with --sysroot meaning that during
buildworld they have a double sysroot.
Reviewed by: bdrewery
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D14780
LLD_BOOTSTRAP (build) is independent of LLD_IS_LD (installed) so they
should not be based on each other.
This is related to upcoming WITH_SYSTEM_LINKER work.
Reviewed by: emaste
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15836
Import the wrapper script from zstdgrep (written by wiz@netbsd.org)
Modify it to support more than just zstd (adding support for gzip,
lzma, xz and bzip2)
Write a simple manpage dedicated for it.
Only use that new wrapper both for gnu grep and bsd grep
Next step will be removing code related to compression format from bsdgrep
Reviewed by: kevans
Approved by: kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D15193
The change makes the user and kernel address spaces on i386
independent, giving each almost the full 4G of usable virtual addresses
except for one PDE at top used for trampoline and per-CPU trampoline
stacks, and system structures that must be always mapped, namely IDT,
GDT, common TSS and LDT, and process-private TSS and LDT if allocated.
By using 1:1 mapping for the kernel text and data, it appeared
possible to eliminate assembler part of the locore.S which bootstraps
initial page table and KPTmap. The code is rewritten in C and moved
into the pmap_cold(). The comment in vmparam.h explains the KVA
layout.
There is no PCID mechanism available in protected mode, so each
kernel/user switch forth and back completely flushes the TLB, except
for the trampoline PTD region. The TLB invalidations for userspace
becomes trivial, because IPI handlers switch page tables. On the other
hand, context switches no longer need to reload %cr3.
copyout(9) was rewritten to use vm_fault_quick_hold(). An issue for
new copyout(9) is compatibility with wiring user buffers around sysctl
handlers. This explains two kind of locks for copyout ptes and
accounting of the vslock() calls. The vm_fault_quick_hold() AKA slow
path, is only tried after the 'fast path' failed, which temporary
changes mapping to the userspace and copies the data to/from small
per-cpu buffer in the trampoline. If a page fault occurs during the
copy, it is short-circuit by exception.s to not even reach C code.
The change was motivated by the need to implement the Meltdown
mitigation, but instead of KPTI the full split is done. The i386
architecture already shows the sizing problems, in particular, it is
impossible to link clang and lld with debugging. I expect that the
issues due to the virtual address space limits would only exaggerate
and the split gives more liveness to the platform.
Tested by: pho
Discussed with: bde
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D14633
