Since cpython-mingw v3.11 (see cpython-mingw commit
8aeb46d09c068a1228e83b29101c17bf1ff0612a), the versionless, stable
ABI libpython3.dll gets installed, along with libpython3.dll.a.
Ideally we would use this, which gets us better flexibility, but
in practice, LLDB fails to link against this, as it doesn't expose
enough of the symbols we use and need.
Previously, we ended up with PYTHON_LIB containing two path names,
which caused CMake to print warnings about ignoring extra paths
on the command line.
This fixes issue #396.
These were missed in ad30b74173.
The mismatch between upload-artifact and download-artifact in
ad30b74173 makes the later steps
fail to download the artifacts from previous steps.
Since 7dcd8ef135147de1576c2863b963ec929a15e8cb in llvm-project
(Dec 15th), LLD can strip out the bundled DWARF debug info directly
when linking, while creating a PDB file, simplifying this test case.
Relevant changes/fixes since the last version:
- Added the new Clang option -fno-auto-import, affecting both code
generation (avoiding generating .refptr stubs) and linking
(passing --disable-auto-import, to avoid subtle runtime errors,
which could happen if code built without .refptr stubs would
autoimport symbols anyway)
- Fix issues with running the toolchain, or building sources on,
network mounts. Previously, there were issues with VirtualBox
shared folders or Remote Desktop shared folders.
- Pass LTO options from the compiler driver to the linker
- Support more LTO options in the linker
- LLD now implements the --icf=safe option properly
- Support using the -S/-s flags in LLD, to strip out DWARF debug
info and symbol table, while producing a PDB file
- Fix LTO issues around __imp_ symbols, making it support building
the base mingw-w64-crt files with LTO
- LLD now doesn't try to detect/add MSVC library directories when
linking in MinGW mode
- Fix building compiler-rt sanitizers, when libcxx is available only
in static form
- Fix building a standalone libclang_rt.atomic_dynamic for MinGW
targets
- Support for the MENUEX resource type in llvm-windres
- llvm-windres now supports referencing filenames in .rc files,
constructed from multiple concatenated string literals
- Various fixes for the llvm-windres option --preprocessor, including
the breaking change to match the new GNU windres behaviour from
binutils 2.36
- Don't look for a GCC in path when Clang is installed next to
a suitable sysroot (mostly relevant for MSYS2)
- Avoid exposing unprefixed mmap symbols in the profiling runtime,
which could lead to misdetections in user code
- Support for reading Windows thread names in LLDB
These helpers are statically linked into each DLL/EXE that uses
them.
They are primarily used for atomic access to variables that are
larger than what the platform natively can support - i.e. primarily
for accessing atomic variables larger than 8 bytes.
The fallback implementations rely on explicit locks (spinlocks
in practice).
As the locks are statically linked into each module that uses the
atomic variable, any concurrent access to such an atomic variable
from two different DLLs/EXEs wouldn't actually end up being
properly atomic.
However cross-module atomic variables (larger than 8 bytes) is
very rare so this isn't deemed to be much of a practical issue.
In GCC based toolchains, the corresponding helpers reside in
a separate shared library, libatomic-1.dll (although it can also
be linked statically).
Don't assume that any host argument indicates cross compiling for
Windows.
Update build-all to pass --host arguments to strip-llvm as well,
for consistency.
This makes the built toolchain usable outside of MSYS2 too.
For running tests, this has another very subtle effect.
If the toolchain is built in the MSYS2 clang64 environment, the
compiler binary depends on libc++.dll. This DLL is found in $PATH,
in /clang64/bin.
When building/running tests, the current working directory will be
e.g. llvm-mingw/test/x86_64. At some point while building/running
tests, the test makefile will copy the llvm-mingw toolchain's
runtime DLLs into this directory in order to be able to execute those
newly built binaries. This also includes another, different libc++.dll.
When a libc++.dll exists in the current directory, this is preferred
over the one found further back in $PATH in /clang64/bin. As this
file is copied in parallel with other build jobs that might be
doing compilation, those compilation processes may end up loading
this other DLL. If fully copied it probably shouldn't be an issue,
but if not fully copied yet, who knows what might happen.
By making sure that there is a libc++.dll in the same directory as
the toolchain executables (rather than expecting it to be found
further back in $PATH), we ensure that this DLL is loaded and used
instead of the one in the current directory.
This should fix stray errors when running tests in the clang64
environment.
This version fixes a race condition in the build, which in most
cases was benign but in rare cases could successfully build a Python
that would crash at runtime.
This skips test that use a lot of memory. In particular, there's
one test that would use up to 6.8 GB of memory, while the GitHub
Actions runners only have 8 GB of memory available.
This parameter was added in 122064a6303eb9c06e0af231f5a4ce145d9a2e67
in the llvm-project main branch, and backported to 17.x in
aa03fba83b17bbfcd9ed869efed2818b503875d6.
This allows seeing the names of tests as they are executed, making
the intermediate log output on github actions more useful. It
also makes it easier to correlate test issues between tests as
they are executed (e.g. if one test causes another one to run out
of memory).
Also run with --time-tests, allowing identifying slow tests.
This was already applied in the separate libcxx test job added in
7483eae1821766a0f84dbd96f5619058f7065008; this backports the change
into the test job in the main build file.
This version fixes the following issues for mingw/windows targets:
- Fix linking the lli tool if built with asan enabled
- Fix compiling for the aarch64 target if specifying -mtune=cortex-a53
- Fix initialization order among constructors within one translation unit
This contains a few bugfixes for mingw use cases:
- LLD in 17.0.1 and the earlier 17.x release candidates looked up
libraries (including libraries named as a relative path) preferring
to search in toolchain relative paths over first testing from the
current directory. In some cases, this could cause cryptic build
failures; see https://github.com/llvm/llvm-project/issues/67779.
- Options that only are relevant for linking, like -mwindows, used
to be accepted (but produce a warning) if used in a compilation-only
job. In the earlier 17.x releases/RCs, such warnings caused an
error instead; see https://github.com/llvm/llvm-project/issues/64464
and https://github.com/mstorsjo/llvm-mingw/issues/371.
This only provides the main binary llvm-cxxfilt; it doesn't
provide the binutils-style frontends named [<triple>-]c++filt.
If we were to provide such frontends, we'd need to make them
default to --strip-underscore for i686 triple prefixes, and
for the prefixless case when the default architecture is i686.
Ninja isn't documented as one of the tools provided by the CI runner
images, but it used to be available implicitly installed before
in the windows-2022 images. Since the 20230918.1.0 image update,
it no longer is available out of the box; see
https://github.com/actions/runner-images/issues/8343.
There was a minor issue with the version information in what
was tagged as 17.0.0, so 17.0.1 is the first proper stable
release on the 17.x release branch.
This brings in a rather large update of the D3D12 header
(d3d12.idl/d3d12.h), which should now be mostly complete and up
to date with the current versions from Microsoft.
Disable Python, to make the LLDB executables more portable,
so they don't rely on whatever version might have been installed on
the GitHub Actions runner.
Relevant changes since 16.0.6 are:
- Improve Address Sanitizer on i686 mingw
- Improve handling of X86 Intel assembly syntax
- Fix using std::wcout/wcin/wcerr with streams configured in wide mode
- Improve handling of the .arch and .arch_extension assembly directives
on aarch64
- Support the --temp-prefix (ignored) and --no-leading-underscore
options in llvm-dlltool
- Make lld warn about too narrow pseudo relocations, simplifying finding
issues that otherwise only show up at runtime
- Improved the tests, making compiler-rt, libcxxabi and libunwind tests
pass in mingw configurations
Versions 4.3 and above only come packaged as .tar.gz and .tar.lz,
and the lzip decompressor is less commonly readily available, thus
switch back to the .tar.gz format.
Ubuntu 20.04 comes with CMake 3.16, so there's no need to install
a custom version of CMake for now (for LLVM 16.x; LLVM 17 will have
the requirement raised to CMake 3.20 though).
Also drop the workaround for git issues in the old version in
Ubuntu 18.04.
The latest releases that are built on GitHub Actions without
docker are based on Ubuntu 20.04 anyway, so there's less demand
for building this with an older version for the sake of
compatibility of the built binaries. For users using the built
docker image as such, having it based on a newer base distribution
is beneficial.
Older macOS versions (macOS 12.2 at least) don't support this
option, while newer macOS versions do support it (macOS 12.6).
The solution is based on https://stackoverflow.com/a/1116890/3115956,
but simplified for this usecase.
These tests should now all pass on both architectures; the
check-asan tests for the static CRT are skipped automatically,
the failures in check-interception have been fixed by compiling
the tests with the --large-address-aware flag, and the
check-asan-dynamic tests on i686 have been fixed - all by
Alvin Wong.
Martin Storsjö