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
If a sysroot was specified, it would take precedence over the Android
NDK sysroot since it would appear after in the command line.
Also only build runtimes for enabled target arches. Many places have
copied this around so create and use supported_android_toolchains.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D113606
-f flags usually use the `=` form. -fdebug-compilation-dir= has been
around for a few months now (since 0c2bb6b446c584ab, both LLVM 12.0
and 13.0 have it), so using it shouldn't be a big problem -- especially
since use_relative_paths_in_debug_info is opt-in anyways.
This is possible after D106314 / 8773822c578a.
Makes the required prepare-code-coverage-artifact.py invocation a bit longer,
but that seems like a good tradeoff.
Differential Revision: https://reviews.llvm.org/D113282
lld/mac should be stable enough to use it as host linker. I've been
using `use_lld=true` in my local args.gn for many months now and it
works fine (and links much faster than ld64).
Differential Revision: https://reviews.llvm.org/D112622
Follow-up to D109708: Using lib_dirs means this will work with ancient gn binaries.
Change the toolchain definitions to make lib_dirs have the right effect, and
pull out lib_switch of each of the tools while here.
This means we now do pass /LIBPATH: to link.exe, but since we invoke it directly
and not through clang-cl, this doesn't actually require D109624. And since this
is built in to GN, we don't need a config to push the flag to dependents.
This is arguably a bit more idiomatic, and it doesn't require folks to update
their GN binaries. No effective behavior change.
Differential Revision: https://reviews.llvm.org/D109763
The cross-compiled lldb-server targets are added to the lldb deps if
Android cross compilation is enabled.
Differential Revision: https://reviews.llvm.org/D109464
This is enough to get the lit-based tests to pass on macOS.
Doesn't yet add build targets for:
- Any LLDB unit tests
- swig bindings
- various targets not needed by lit tests
LLDB has many dependency cycles, something GN doesn't allow. For
that reason, I've omitted some dependency edges. Hopefully we can
clean up the cycles one day.
LLDB has a public/private header distinction, but mostly ignores it.
Many libraries include private headers from other modules.
Since LLDB is the first target the LLVM/GN build that uses Objective-C++
code, add some machinery to the toolchain file to handle that.
Differential Revision: https://reviews.llvm.org/D109185
eecd5d0a broke non-clang host builds.
Some crt code is not always built with the just-built clang.
0da172b checked if the compiler is clang, not assert that the compiler
is clang.
libclang is only built as static library in the GN build at the
moment, which means we now generate a .exports file form a version
script and then link.exe and ld64 inputs from the .exports file
but don't use the version script, but hey.
Apparently ubsan errors are non-fatal by default. If you introduce UB
into LLVM and run the tests, if errors are not fatal, the test will
still produce the expected output and the tests will pass. In order to
make ubsan errors show up as test failures, they have to be made fatal.
Pass the -fno-sanitize-recover=all flag to make it so.
Differential Revision: https://reviews.llvm.org/D103298
Avoids a warning from the linker. The user still has to put the resource
directory on the linker search path, and I can't find a clean way to do
that automatically in gn.
- D96404 defaulted to libunwind which isn't provided by NDK r21
(or r22), so specify -rtlib=libgcc on non-arm32.
- D97993 means that we need to use --gcc-toolchain instead of -B
to let the driver find libgcc.
With this, you can set `clang_base_path = "//out/gn1"` in `out/gn2/args.gn` and
the build in out/gn2 will use clang and lld from out/gn1.
Setting `clang_base_path` to an absolute path (with e.g.
`clang_base_path = getenv("HOME") + "/src/..."`) should behave as before.
Differential Revision: https://reviews.llvm.org/D97989
The new Darwin backend for LLD is now able to link reasonably large
real-world programs on x86_64. For instance, we have achieved
self-hosting for the X86_64 target, where all LLD tests pass when
building lld with itself on macOS. As such, we would like to make it the
default back-end.
The new port is now named `ld64.lld`, and the old port remains
accessible as `ld64.lld.darwinold`
This [annoucement email][1] has some context. (But note that, unlike
what the email says, we are no longer doing this as part of the LLVM 12
branch cut -- instead we will go into LLVM 13.)
Numerous mechanical test changes were required to make this change; in
the interest of creating something that's reviewable on Phabricator,
I've split out the boring changes into a separate diff (D95905). I plan to
merge its contents with those in this diff before landing.
(@gkm made the original draft of this diff, and he has agreed to let me
take over.)
[1]: https://lists.llvm.org/pipermail/llvm-dev/2021-January/147665.html
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D95204
This is a tiny bit messy because compiler-rt needs different sysroots for
macOS, iOS, etc. We want sysroot.py to create something that is a hermetic
representation of all build deps, so it needs to create a directory that
contains all needed SDKs, and these subdirectories are then passed to
cmake which passes each of these _subdirectories_ as different -isysroot
flags while building the runtime libraries.
Differential Revision: https://reviews.llvm.org/D96958
CMAKE_SYSROOT works fine here, and `sysroot.py make-fake`
borders on trivial here, but I suppose it's still nice
to have a consistent script to set these up across platforms.
And these are the platforms where we can do real sysroot management one
day.
Differential Revision: https://reviews.llvm.org/D96882
