Currently, the "macos-latest" runners aren't really the latest
version - on the contrary, they're running the oldest HW/OS.
Currently, there are macos-12, macos-13 and macos-14, and macos-latest
are the macos-12 ones.
The macos-14 ones run on Apple Silicon.
Previously, the macos-12 runners have usually managed to run the build
job in less than 3 hours. However, lately, the jobs often end up
taking much longer, over 5 hours, and have ended up exceeding the
6 hour timeout occasionally, even if they still also some times run
in the expected time of less than 3 hours.
Switch to the faster macos-14 runners (which can complete the build
job in around 1 h 40 min), to avoid these timeouts.
This sets the variable CLEAN=1 after building the tools, which makes
all the builds of the runtime libraries remove old build dirs
before building.
This is similar to, but has a slight different purpose than
the existing --wipe-runtimes, which removes the installed runtime
files. Both are useful when testing various build configurations
and investigating issues, for different testing scenarios.
If not building with FULL_LLVM the directory is empty or doesn't exist.
Otherwise it contains the LLVM headers. In either case merge the architecture specific ones into it.
The DWARF debug info should work just as well.
Since 8c03f400a837dc9333e54ab371e7904aa2bec43c in llvm-project,
llvm-symbolizer prefers DWARF over PDB if there is a DWARF section
in the inspected executable. Thus, in order to use PDB, one would
have to strip out any remnants of DWARF debug info from the executable,
like in run-lldb-tests.sh (e.g. by -Wl,-s).
For the purposes of this test, simplifying the setup to use DWARF
works just as well.
When calling make_indirect_call with a parameter which is known,
Clang, since the 18.x release, can end up producing a specialized
version of the function which omits the cfguard check call (as the
target is known) and calls the known target directly.
The function is marked with a noinline attribute, to avoid
the compiler optimizing out the cfguard check call when the
target is known, but even with a noinline function, the compiler
apparently can make a separate specialized version of it.
To avoid the compiler doing such optimizations, reference the
target function via a global variable - the compiler can't assume
anything about the contents of them (they could be altered between
initialization and reading them later).
This fixes the cfguard invalid_icall test with Clang 18.x, when
compiled with optimizations enabled.
6b6b1240e2 tried to build a
multiplatform image, by building two images separately and pushing
them one at a time, with the same name (but with a different platform).
This doesn't work as expected; the last push for the image name
replaces earlier pushes. So depending on which push finishes
last, we'd end up with either an amd64 or arm64 image, but not
one that supports both.
Instead, push two separate images just with push-by-digest, and
then create the actual tag with "docker buildx imagetools create".
Alternatively, we could build all platform variants of the main
image with Dockerfile.toolchain, simplifying the setup significantly.
The contents of such a build is marginally different though, so
keep the amd64 image as it was, for now, compiled in that environment.
add an option --host-clang which will skip building llvm,
and instead provide symlinks and wrappers for clang and
llvm tools.
Currently the clang version is detected, but it does not
affect the llvm version that will be downloaded and used.
The total number of exported symbols in this build configuration has
now reached the limit for the number of exported symbols in a DLL,
with the latest version of llvm-project from git.
This isn't an issue when building with Clang, as it marks many
symbols as excluded from auto-export.
This adds the following:
- LLD now uses the SOURCE_DATE_EPOCH env variable for setting the
COFF header timestamp
- LLD now also supports --lto-emit-asm and -plugin-opt=emit-llvm
in the mingw linker interface
This raises the versions of bundled software, providing e.g.
autoconf 2.71, which is needed for Python 3.12.
As the releases are built (without a surrounding extra container)
on GitHub Actions these days, we don't need to hold the docker
images back to an old version for the sake of compatibility;
instead, updating to a newer version provides more modern tools
for users of the docker image.
Previously, when echoing the definition of BUILD_DATE to
$GITHUB_OUTPUT, that doesn't make it available as an environment
variable. (And if it would be echoed to $GITHUB_ENV, it still
wouldn't take effect until the next step within the same job either.)
Therefore, this previously set BUILD_DATE to $(date -d "" +%s),
which seems to produce a timestamp corresponding to the start of
the current day.
This sets SOURCE_DATE_EPOCH to the commit timestamp, toolchains
should pick up timestamps from this variable.
The same sources ideally would produce the same binary, see
https://reproducible-builds.org.
Set the timestamps within the tar archives to the start of the
CI pipeline.
Sort the archive contents.
The generated tar archives contain the uid/gid of the builder,
if unpacked as root on another system those will denote nothing
or an unexpected user/group.
The expectation would be uid/gid = 0.
Use a simple enough tar format as well.
The Mac version of tar (bsdtar?) does not support those flags,
for CI the separate gnu-tar is installed.
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
Martin Storsjö