Remove --unwindlib=none flag that was added by D143598. It is required
to not pass this flag when linking binaries. With this flag, linking
e.g. llvm-symbolizer will fail.
There was a missing dependency from most targets to the implicitly linked
libraries (libunwind and builtins), which was causing the build for those
targets to fail when they were built on their own. I never noticed this
because I always build the implicitly linked libraries together with
their dependencies. Make the dependency explicit by introducing a new
target //llvm/utils/gn/build/libs/implicit representing the platform's
implicitly linked libraries, and depend on that from the LLVM libraries,
so that "normal" binaries like llvm-symbolizer will have all of their
dependencies available.
D143598 set the arch subdirectory to i686 for Android. However, the arch
subdirectory on Android is i386, and has been for a long time.
$ find android-ndk-r* -name i386
android-ndk-r18b/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/7.0.2/lib/linux/i386
android-ndk-r19/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/8.0.2/lib/linux/i386
android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/8.0.7/lib/linux/i386
android-ndk-r21-beta1/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/lib/linux/i386
android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/9.0.8/lib/linux/i386
android-ndk-r22/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/11.0.5/lib/linux/i386
android-ndk-r23-beta5/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/12.0.5/lib/linux/i386
android-ndk-r24/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.1/lib/linux/i386
android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/14.0.7/lib/linux/i386
Using the wrong name prevents Clang from being able to find libunwind.a on
x86. Fix the code to use i386 as the arch subdirectory, consistent with
the NDK.
Bring back -Wl,-z,defs which was removed for Android by D143598, presumably
because of the missing unwind library.
Differential Revision: https://reviews.llvm.org/D146266
Only supports ASAN mode right now. Standalone requires a some more plumbing so it will be a follow-up.
Mac-only but I suspect this will be fine on Linux also since it's based on the check-asan file, will follow up after testing.
Differential Revision: https://reviews.llvm.org/D153651
Adds build files for libraries, tools, and tests -- everything except
the runtime.
Doesn't hook up bolt in the main BUILD.gn file yet -- I want to verify
that it builds on Linux, macOS, Windows before doing that. (I've only
checked on macOS so far.)
`ninja check-bolt` passes on macOS with this.
(I locally bumped the deployment target to macOS 10.12 for that. bolt/ uses
std::mutex quite a bit, which requires 10.12.)
Differential Revision: https://reviews.llvm.org/D138355
After bc39d7bdd497 (ported to GN in 94c00c10e), libclang uses symbol_exports,
and clang/test/LibClang/symbols.test wants the versioned name to be `LLVM_[0-9]$`
instead of `FOO`.
The two flags do the same thing, but the OS is called macOS these days.
(The new flag is 5 years old: https://reviews.llvm.org/D32796)
No behavior change.
`use_ubsan=true` seems to Just Work on macOS, so allow it.
https://reviews.llvm.org/D122862 broke use_asan=true, use_tsan=true, and
use_ubsan=true builds on Linux too. This makes this go again by explicitly
disabling asan, tsan, and ubsan for the baremetal part of the build. See
discussion on https://reviews.llvm.org/D122862 for other possible approaches.
Differential Revision: https://reviews.llvm.org/D127906
After years of tablegen being the only host binary we run as part
of the build, we're now in the process of growing at least two more:
- make_confusable_table (https://reviews.llvm.org/rG180bae08a04d)
- pseudo-gen (not yet fully hooked up in the GN build, but I have
a local branch that hooks it up)
Factor out the few lines we need for running a host binary as part of the
build.
No behavior change.
Differential Revision: https://reviews.llvm.org/D126963
This reverts commit e2ee8bf9818189b900e65d6ea8f1ae6fc75455ce.
This change is beyond my ability to integrate into Google's internal
build configuration tonight.
Currently, the Bazel build uses static, checked in [llvm-]config.h files
in combination with global macro definitions to mimic CMake's generated
headers. This change reuses the write_cmake_config.py script from the GN
build to generate the headers from source in the same way. The purpose
is to ensure that the Bazel build stays up to date with any changes to
the CMake config files. The write_cmake_config.py script has good error
checking to ensure that unneeded, stale variables are not passed, and
that any missing variables are reported as errors.
I tried to closely follow the logic in the GN build here:
llvm/utils/gn/secondary/llvm/include/Config/BUILD.gn
The duplication between this file and config.bzl is significant, and we
could consider going further, but I'd like to hold off on it for now.
The GN build changes are to move the write_cmake_config.py script up to
//llvm/utils/write_cmake_config.py, and update the paths accordingly.
The next logical change is to generate Clang's config.h header.
Differential Revision: https://reviews.llvm.org/D126581
Only applies linux for now.
This prevents warnings with use_thinlto like
bfd plugin: LLVM gold plugin has failed to create LTO module: Not an int attribute (Producer: 'LLVM15.0.0git' Reader: 'LLVM 13.0.1')
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D125399
Our support for building for baremetal was conditional on a default
off arg and would have failed to build if you had somehow arranged
to pass the correct --target flag; presumably nobody noticed because
nobody was turning it on. A better approach is to model baremetal
as a separate "OS" called "baremetal" and build it in the same way
as we cross-compile for other targets. That's what this patch does.
I only hooked up the arm64 target but others can be added.
Relanding after fixing Mac build breakage in D123244.
Differential Revision: https://reviews.llvm.org/D122862
When cross-compiling from Mac to non-Mac, we need to use the just-built
llvm-ar instead of libtool. We're currently doing the right thing
when determining which archiver command to use, but the path to ar
and the toolchain dependencies were being set based on the host OS
(current_os evaluated in host OS toolchain), instead of the target
OS. Fix the problem by looking up current_os inside toolchain_args.
Differential Revision: https://reviews.llvm.org/D123244
Our support for building for baremetal was conditional on a default
off arg and would have failed to build if you had somehow arranged
to pass the correct --target flag; presumably nobody noticed because
nobody was turning it on. A better approach is to model baremetal
as a separate "OS" called "baremetal" and build it in the same way
as we cross-compile for other targets. That's what this patch does.
I only hooked up the arm64 target but others can be added.
Differential Revision: https://reviews.llvm.org/D122862
macOS 12.3 no longer ships non-3 python.
Almost all of these scripts were launched by ninja, and the GN files
already told it to run them under python3, so this is a fairly small
change. The main effect is that if you run them manually, you now
get the same behavior.
(A small set of scripts, gn.py, gen.py, sync_source_lists_from_cmake.py,
are for manual running. For these, it is an actual change.)
Differential Revision: https://reviews.llvm.org/D122345
If `clang_base_path` is set, it must now point to a directory that contains
an lld-link built with D118070.
(If this is a problem for anyone, we can guard this behind a
lld_link_understands_winsysroot gn arg, but let's see if we can get away
without that for now.)
With this, it's possible to build everything in a normal cmd.exe Window,
an MSVC shell isn't needed \o/
(Assuming you set `clang_base_path`, and you set `sysroot` to a directory
that contains a win sysroot. If you have MSVC installed,
`python3 llvm\utils\sysroot.py make-fake --out-dir=my-sysroot` and
setting `sysroot = "//my-sysroot"` in args.gn works, for example.)
Differential Revision: https://reviews.llvm.org/D121871
Now that the minimum version version of MSVC required to build LLVM has
been bumped, we see
../../llvm/include\llvm/Support/Compiler.h(94,2): error: LLVM requires
at least VS 2019.
#error LLVM requires at least VS 2019.
e.g. http://45.33.8.238/win/53703/step_4.txt
1920 corresponds to the earliest version of VS 2019.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D118713
With these changes, check-asan passes on Linux and Windows.
There are a couple libraries we need to add support for, asan_static, asan_preinit, and the shared library version of asan proper.
Since we need to build the asan proper sources twice, once with -DASAN_DYNAMIC and once without, those sources are no longer in a source_set.
Much of the check-asan target is taken from the existing check-hwasan target.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D118307
crt_code seems to correspond to SANITIZER_COMMON_CFLAGS which contains -fno-builtin.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D118288
The default hasn't worked in over 9 months now.
Getting a friendly error message if this isn't set is more useful than getting
a bad default value.
Differential Revision: https://reviews.llvm.org/D115833
In release+sym builds (-O2 -g), reduces time to link `clang`
from 2.3s to 1.3s (-42%).
In debug builds (-g), reduces time to link `clang`
from 5.4s to 4.5s (-17.4%).
See the phab review for full `ministat` numbers.
In the CMake build this is opt-in via LLVM_USE_SPLIT_DWARF.
Since the GN build is targeted at developers, enabling it by default
seems like a better default setting here. (If it turns out to cause
problems, we can add an opt-out.)
Time to load the binary into gdb and to set a breakpoint is unchanged.
Time from `run` to hitting a breakpoint in `main` feel a bit faster
(~4s -> ~2s), but I dind't do a careful statistical anlysis for this.
Differential Revision: https://reviews.llvm.org/D115040
[NFC] As part of using inclusive language within the llvm project and to
match the renamed master branch, this patch replaces master with main in
sync_source_lists_from_cmake.py.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D113926
