Commit de6feefdb7 limited the amount of debuginfo generated for clang
and other llvm-related executables. This was done to save disk space and
memory during building, but it makes debugging any of these executables
much harder.
Add a new src.conf(5) setting, WITH_LLVM_FULL_DEBUGINFO, to generate
full debuginfo instead. This is off by default, but could for example be
enabled for release builds or snapshots, so llvm executables are easier
to debug.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43839
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the
last commit before the upstream release/17.x branch was created.
PR: 273753
MFC after: 1 month
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.
PR: 258209
MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.
PR: 255570
MFC after: 6 weeks
When building natively on RISC-V, linking the bootstrap clang-tblgen
fails with:
ld: error: undefined symbol: llvm::EnableABIBreakingChecks
>>> referenced by PrettyStackTrace.cpp
>>> PrettyStackTrace.o:(.sdata+0x0) in archive
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>> referenced by Signals.cpp
>>> Signals.o:(.sdata+0x8) in archive
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>> referenced by Timer.cpp
>>> Timer.o:(.sdata+0x28) in archive
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
This is likely due to Error.h's inclusion of abi-breaking.h. It's
unclear why this only affects RISC-V, but perhaps relates to its more
eager use of .sdata due to the ABI's support for linker relaxations.
Regardless, this is theoretically an issue for all architectures.
Reported by: Dennis Clarke <dclarke@blastwave.org>
Reviewed by: dim
Tested by: mhorne
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D28367
When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils
ld.bfd from ports for the bootstrap, as this is the only modern linker for
ELFv1 host tools.
As binutils ld.bfd is rather strict in its handling of undefined symbols,
it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.
Reviewed by: dim, emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23072
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.
PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream
llvm revision r271821 disabled the use of std::call_once, which causes
some fallback functions from Atomic.cpp to be used instead.
Reported by: Mark Millard
PR: 214902
X-MFC-With: 309124
* Bootstrap llvm-tblgen and clang-tblgen with a minimal llvm static
library, that has no other dependencies.
* Roll up all separate llvm libraries into one big static libllvm.
* Similar for all separate clang and lldb static libraries.
* For all these libraries, generate their .inc files only once.
* Link all llvm tools (including extra) against the big libllvm.
* Link clang and clang-format against the big libllvm and libclang.
* Link lldb against the big libllvm, libclang and liblldb.
N.B.: This is work in progress, some details may still be missing.
It also heavily depends on bsd.*.mk's support for SRCS and DPSRCS with
relative pathnames, which apparently does not always work as expected.
For building llvm, clang and lldb though, it seems to work just fine.
The main idea behind this restructuring is maintainability and build
peformance. The previous large number of very small libraries, each
with their own generated files and dependencies was slow to traverse
and hard to understand.
Possible future improvements:
* Only build certain targets, e.g. for most regular users having just
one target will be fine. This will shave off some build time.
* Building the big llvm, clang and lldb libraries as shared (private)
libraries.
* Adding other components from the LLVM project, such as lld.
