Besides a version bump, the following changes have been made to our
toolchain infrastructure:
- LLVM/Clang is now built with -march=native if the host compiler
supports it. An exception to this is CI, as the toolchain cache is
shared among many different machines there.
- The LLVM tarball is not re-extracted if the hash of the applied
patches doesn't differ.
- The patches have been split up into atomic chunks.
- Port-specific patches have been integrated into the main patches,
which will aid in the work towards self-hosting.
- <sysroot>/usr/local/lib is now appended to the linker's search path by
default.
- --pack-dyn-relocs=relr is appended to the linker command line by
default, meaning ports take advantage of RELR relocations without any
patches or additional compiler flags.
The formatting of LLVM port's package.sh has been bothering me, so I
also indented the arguments to the CMake invocation.
This commit backports the LLVM commit that adds support for the
`--update-section` flag to llvm-objcopy. We use this feature of GNU
objcopy to embed the symbol map in the kernel.
The corresponding LLVM Phabricator Differential Revision can be found
here: https://reviews.llvm.org/D112116
This patch is identical to the upstream commit, except for two hunks
that had to be changed as they didn't apply cleanly.
With this update, we now use our custom `serenity` Clang target, which
means that all system-specific compilation options (e.g. default PIE,
header search paths) will be handled automatically.
This port has been tested to build `Source/little` on all 4
toolchain-architecture pairs. Furthermore, `lib(std)c++` headers are
picked up correctly and our AK headers can be included without any
issues.
Due to recent kernel fixes related to memory-mapped files, the LLD
linker can now be used by default, so there's no need to also build the
GCC port alongside this.
Although our patches cover building libLLVM as a shared library, this is
currently not enabled by default, as DynamicLoader is very slow in
dealing with such a large number of relocations.
We may need entries with spaces in makeopts, installopts, and
configopts, and at that point we should also convert depends and
auth_opts to avoid confusion.
Now that we're generating the CMake toolchain file in the build
directory, we need to redirect the ports that use CMake to the new
location. Looking into this showed that there's still a bunch of work to
do in general to make the ports agnostic to which toolchain they're
using, there's a lot of hard-coded ${ARCH}-pc-serenity-gcc assumptions
still here.
