As macOS itself doesn't ship with libzstd, avoid picking it up from
third party intallations.
CMake even looks for things in directories outside of $PATH;
for Darwin targets, CMake includes /opt/homebrew in
CMAKE_SYSTEM_PREFIX_PATH which gets searched automatically.
When some of the parameters to standard C functions are known
constants, the compiler can optimize out the call to the actual
function.
When built with fortification enabled, the compiler previously
didn't actually end up calling the __<func>_chk functions in
most cases, as it could optimize out much of the calls. Now all
tested function calls should end up emitted as intended, making
this actually do functional testing of the __<func>_chk function
implementations.
The literal NAN in MSVC is a negative NAN, while it is a positive one
in other environments. (strtod("NAN", NULL) did return a positive NAN
though.) In most tests where we test that NANs are preserved, the exact
sign doesn't matter much as long as it matches, but for some tests, it
does matter. Change to using variables with known representation
in the tests where it matters.
Also add a LL suffix to make a tricky constant more correct.
In MSVC, the variable initialization
long long i = -2147483648;
actually sets the variable to the positive value 2147483648 (both
in MSVC 2019 and 2022).
The macros F() and L() etc were meant for providing constants for
the tests, without the compiler seeing them as constants, to
avoid optimizing out the entire functions that are to be tested.
However in practice, the compiler is also able to optimize out
e.g. a call to strtol("42", NULL, 0), so this didn't have the
intended effect.
Instead make the macros wrap through a no-op function, but which
is indirected via a global function pointer. The compiler can't
reason about global variables keeping their values (they could be
modified by e.g. a constructor in a different object file, before
running the main function). This avoids needing to pass all values
through strtod/strtol etc.
Change some constants like 123456789012345, which are seen by
the compiler as integer constants (which aren't exactly representable
in floating point form) into 123456789012345.0, which the compiler
won't complain about being inexact.
Using two dashes for this option name is more idiomatic for
long GNU options (using only one dash only is supported for options
where it doesn't conflict with single-character options; it does
work for "-pdb" but "--pdb" is more correct).
Stop documenting the separate argument form "-Wl,--pdb,<filename>".
If noone would use this form, one could consider switching the tools
over to interpret "-Wl,--pdb" as a boolean option (optional_argument
instead of required_argument in getopt_long) as a less awkward syntax
for "-Wl,--pdb=".
PDB output now does work for armv7 (earlier it used to error out),
and the PDB output does work properly on aarch64.
(The recently added tests in run-lldb-tests.sh passes successfully on
aarch64. Debugging on armv7 with LLDB has got a few known issues though,
both with DWARF and with PDB, while WinDbg and/or Visual Studio might
work better.)
When rebuilding in an already built directory, cmake does use
the cache file, containing what variables were set to previously.
When changing build configuration (building with a different prefix,
or changing build configurations) this can often result in failed
cmake runs.
Wipe the cache (and the rest of the cmake temp files) by default.
This makes sure that the full cmake configuration is run each time
when running the build scripts, just like it does the first time.
(This doesn't remove the build artifacts; if nothing of significance
has changed, ninja would still reuse old built files.)
By setting the env variable NO_RECONF, this behaviour can be skipped,
rerunning cmake without wiping the cache inbetween. (For cases where
the user knows that the configuration hasn't changed since the last
build, this can speed up the cmake execution time a bit.)
This is necessary for CMake to detect working IPO (LTO); if the
compiler is named <target>-{gcc,clang}, CMake expects to find
matching tools named <target>-llvm-{ar,ranlib} too. (The CMake
module CheckIPOSupported and function check_ipo_supported expects
to have CMAKE_LANG_COMPILER_AR and ..._RANLIB set to working tools;
the Clang-FindBinUtils.cmake module looks for tools named
llvm-ar/llvm-ranlib with the same prefix as the compiler.)
Normally, we'd split the string at the last dash. However if the
tool name is "llvm-<tool>", make sure to include "llvm-" in the
tool name part when splitting the executable name.
In llvm-wrapper, don't add a duplicate "llvm-" prefix for the tool
name in these cases.
This matches how the compiler driver normally includes default
linked libraries; the user provided -l flags are passed first,
followed by the compiler's default ones. That allows a user
specified library to override the default ones.
This makes sure that if a user provides -lwindowsappcompat, it
gets linked before -lwindowsapp, which makes a difference for
symbols that are provided in both (such as e.g. LoadLibraryW).
Run this for both i686 and x86_64, as we only test lldb with the
native architecture of the lldb executable (which is assumed to
be the same as the default architecture of the clang executable).
If the low byte of the stack cookie happens to be zero, we
previously wouldn't trigger any error.
This avoids accidentally failing to trigger the stack protector
once per 256 runs, roughly.
These are functions that, when built with "-D_FORTIFY_SOURCE=2 -O2",
can end up calling the corresponding __<func>_chk functions - thus,
this can be used for testing those functions.
Ideally we'd wipe the whole test/<arch> directory before running
the tests (we do that if CLEAN is set), but here we only wipe out
the specific ones that can affect how new tests are built and linked.
Notable changes are:
- Require strict matches for defines for precompiled headers in GCC
style PCH directories. This fixes some cases of building DLLs and
static libraries at the same time with libtool, with PCH.
- Support for the new embedded -exclude-symbols: directive in LLD
- Fix LLD crashes if including object files containing export directives
via the --undefined/-u option
Notable changes:
- Fixed using the strtof() function from UCRT instead of accidentally
using a wrapper that internally calls strtod()
- Range/accuracy improvements for complex trigonometry functions
- Fixed the callback declaration for the EnumPageFiles API
- Fixed the declaration of the addrinfoex structs
- The usual assorted API updates
This should get a patched host compiler for the clang64 environment,
supporting symbol visibility, avoiding exporting too many symbols
from the dylibs.
For the mingw64 build (with GCC, which doesn't support symbol
visibility on Windows), the number of exported symbols
seems to be slightly lower, so we don't hit the limit of exported
symbols quite yet.
The configure script of winpthreads tries to execute the "cmp"
command (pulled in via the libtool macros), visible as errors in
the build logs. (The issue doesn't seem to make any practical
difference though.)
Use the one without assertions for cross-building toolchains, as the
one with assertions is too slow. In practice, one or more of the cross
toolchain builds end up timing out (exceeding the 6 h limit) almost
every day in the scheduled builds, requiring reruns (sometimes
multiple reruns) to complete successfully in time.
(There seems to be a big variation in what actual runner the jobs
end up using; some runners complete the cross builds in around 4 h,
while some are much slower, and seem to require 5-6 hours or more.)
In practice, during the 2 months that I've had scheduled jobs
running on Github Actions, there haven't been any failed asserts
triggered and caught in the cross builds (but once in the cross builds
of ffmpeg, which still keep using a toolchain with asserts enabled).
We normally don't install all tools (including llvm-config), or we might
have stripped them out, but the system distro might have installed a copy
of llvm-config (for a different unrelated installation of llvm).
Some compiler-rt runtimes (such as xray and orc) use this for finding
the main llvm headers.
When building compiler-rt, we really don't want it to pick up any random
version of llvm headers found on the system, but keep using the matching
headers from the monorepo instead.
Adding the include directory of a system provided set of llvm headers
is especially fatal if that directory isn't a subdirectory containing
only llvm headers, but contains other system headers too.
In particular, on msys2, the include directory (pointed at by "llvm-config
--includedir", and also set by including LLVMConfig.cmake which is
pointed at by "llvm-config --cmakedir") is the main system include
directory. Including this can also get headers for a system install
of libc++ headers (for the clang64 msys2 distro) - and using libc++
headers with a second set of libc++ headers in the include path is
fatal (due to include_next not finding the plain C header but finding
a second libc++ header).
Just try to make sure that we don't pick up any unintended headers.
Latest git llvm-project has switched to requiring C++17, while
lldb-mi still is built in C++14 mode. This makes the scheduled builds
fail. Therefore, disable building lldb-mi for now in the scheduled
builds, until this has been fixed in the latest git main versions
of lldb-mi.
46efff459a regressed this aspect,
where libLLVM-<version>.{so,dylib,dll} was meant to be kept, but
also ended up keeping libLLVM<name>.a. (This only matters if trying
to strip a build done with --full-llvm.)
Since LLVM 15, libc++experimental should work fine with libc++
configured for shared linking, and libc++experimental is enabled
unconditionally, and LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY is
ignored now.
This avoids needing to run the cmake configure for the nested
native build.
This tool (part of clang-tools-extra) is new in LLVM 15.0.0
(and the cmake setting for specifying the binary was backported
after the 15.x branch was made, but before rc1 was tagged).
This command isn't a standard tool; different distributions have
different implementations, and e.g. Fedora doesn't ship it by
default.
Settle on using "command -v $tool >/dev/null" for tests about whether
a tool is available. (We could also use "hash $tool 2>/dev/null" as we
already had in build-all.sh, but settling on using "command -v"
everywhere, for consistency and simplicity.)
Since 93010544a813dfbfa64dd7cee68785f572f974d1 in llvm-project
(Jun 22nd), this no longer is needed for being able to build
native tools with a nested cmake in a cross build. (If building in
the same tree as a previous native build, build-llvm tries to pick
up the tblgen tools from there, so in such cases, this doesn't
make any difference and the nested native cmake invocation never
was executed.)
Since bedf657d0f4c54ffe9ef4303382657a74296b544 in llvm-project
(May 18th), a static libc++ built at the same time as a shared one
no longer contain dllexport directives, making that library actually
usable.
Since dfa88927ae1411ccc3b248b7e624f2acf623d947 (Jun 6th), the
libc++ headers no longer have dllimport attributes, making the headers
installed from a build containing a shared library usable both
for the shared and static library, without the user having to set
any specific defines.
These two changes allow removing the manual build workarounds of
building the libraries in separate CMake invocations in a specific
order.
Notable changes are:
- Fix stripping Rust executables with .rmeta sections
- Implemented support for SEH unwind info on the armv7 target
- Fix compiling files specified with an absolute \\?\C:\... style path
- Implemented support for the --disable-reloc-section option in lld
- Lots of improvements in LLDB on Windows (thanks to Alvin Wong!)
- Support for GNU debuglink
- Fix loading DLLs from a ramdisk
- Fix starting executables without including the '.exe' suffix
- Fixed crashes on getting nested exceptions
- Use the right C++ ABI for mingw environments
Other changes that simplify how to build the toolchain:
- Improvements to how libcxx/libcxxabi/libunwind are built for Windows
(and in particular mingw), allowing building both shared and static
libraries in the same cmake build
- Avoids needing to set an empty CROSS_TOOLCHAIN_FLAGS_NATIVE when
cross compiling LLVM
Notable changes are:
- Fix building for armv7 with SEH enabled
- Implement _set_com_error_handler and _com_raise_error in comdef.h
- Add import libraries for older msvcrXX.dll versions
- Redirect access() to __mingw_access() on UCRT
- Assorted updates to Windows APIs
Zstd is available and gets autodetected, but it's only available in
native form, not in arm64 form.
Also, for the existing workaround, instead of entirely disabling lldb,
one could pass -DLLDB_ENABLE_PYTHON=OFF instead.
Test building the toolchain on all supported platforms for building
it (linux, macOS, msys2). Produce cross-built standalone toolchains
that run on Windows for all 4 supported architectures.
Run scheduled builds (daily), built with the latest git versions of
most components. For scheduled builds, the linux toolchain is built
with assertions enabled, as latest git version of llvm occasionally
can have regressions, and many such are caught by having assertions
enabled and building enough code that exercise many code generation
cases.
A regular GCC install doesn't provide tools like <triple>-{cc,c99,c11},
so there's probably not much need to include them.
Some distributions of tools may provide tools with the names "cc",
"c99" and "c11" though, as custom frontends or symlinks to the
regular compiler. Therefore, keep the unprefixed tools with these
names.
Check for the prescence of the llvm-tblgen binary in addition to just
checking whether the llvm/build or llvm/build-asserts directories
exist.
In cases where having multiple build directories around, where some
are older than others, it's now possible to clarify which one to use
for tools by just removing the llvm-tblgen binary from the other ones.
Also check for the prescenece of each individual tool before setting
it; this fixes builds where the native build might not have all
components enable as as enabled in the cross build.
The install(1) tool on macOS doesn't support the -D option for
creating directories at the same time while installing files.
Therefore, run a separate step for creating directories. Doing that
with "mkdir -p", even if install(1) also could do that with the -d
option (likewise with a separate command).
Also stop specifying the destination file name, when it's equal to
the source files, now that we know that the destination directory
already exists.
Compared with RC2, the only notable change for mingw targets is
that sections named .debug_* are sorted to the very end of the
image, after any other discardable sections, avoiding leaving gaps
if stripping such executables. (This can affect rust binaries with
a .rmeta section.)
This fixes the v*scanf functions when using msvcrt.dll, if using more
than 30 format conversions, fixes error handling in the btowc
function in libmingwex, and adds a missing (void) in a function
prototype in winpthreads, adds the fwpuclnt import library for aarch64,
plus other assorted header/interface updates.
This installs a bunch of new tools in the bin dir, namely the following:
clang-apply-replacements
clang-change-namespace
clang-doc
clang-include-fixer
clang-move
clang-query
clang-reorder-fields
clang-tidy
clangd
find-all-symbols
modularize
pp-trace
run-clang-tidy
These are stripped out by strip-llvm, but clangd and clang-tidy
are kept.
While lldb can be used as a cross debugger, it's probably mostly
used when run on the same target as the code is executed on.
Since it's a mostly optional component in the toolchain, allow
passing --disable-lldb to build-llvm.sh to skip it.
Allow setting up the projects with symlinks by passing --symlink-projects
to the build script.
The setup with symlinks is mostly useful in development setups, where
one wants to share ccache across multiple checkouts.
If the SYNC variable is set when running build-all.sh, all the
individual scripts will try to check out the intended version
before building. All scripts that build projects from llvm-project
(build-libcxx.sh, build-compiler-rt.sh, build-openmp.sh) call
build-llvm.sh with CHECKOUT_ONLY=1 to make sure the right version
is checked out (as one can call the scripts individually too).
If the llvm-project directory was a full (non-shallow) checkout,
the repeated fetch was quick as git knew that it had the fetched
reference already. But in a shallow clone, a new shallow fetch
would refetch the whole object tree for the targeted reference.
Using "git cat-file -e" we can check whether a specific object
exists in the local checkout, avoiding needlessly refetching
everything.
However, when fetching a tag using shallow fetch (git fetch
--depth 1 origin "$LLVM_VERSION"), it would only fetch the
commit object for that tag, not the tag itself. By specifying
'tag "$LLVM_VERSION"' in this case, we get the tag object itself,
so that we later can check whether "$LLVM_VERSION" exists in the
local checkout. But this requires guessing whether a specific
"$LLVM_VERSION" is a tag or a commit.
This reverts commit bd9e16f732.
It turns out this actually isn't needed; since switching to
building via the llvm-project/runtimes directory (in
7b1d05f545), the cmake build
pulls in HandleLLVMOptions.cmake, which checks for and adds
-ffunction-sections and -fdata-sections if supported. Therefore,
we don't need to specify it manually at all.
Notable changes include:
- Default to DWARF 4 instead of 5 for the mingw target
- Fix the section name encoding in llvm-objcopy/llvm-strip, if the output
binary has more than 10^6 bytes of string table
Clang's general default dwarf version was raised from 4 to 5 in
d3b26dea16108c427b19b5480c9edc76edf8f5b4 in llvm-project (Jan 23
2022) before the 14.0.0 branch, but dwarf 5 on Windows seems to not
work with either LLDB or GDB.
Thus force the default back to 4 here as a temporary workaround, and try
to set the default back to 4 for mingw targets in Clang for later
releases (https://reviews.llvm.org/D119326).
Martin Storsjö