Add a patch to let llvm's InstrProfiling modules know serenity supports
all the Unix-y features required to make -fprofile-instr-generate and
-fcoverage-mapping work properly on target.
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.
* x11 package name has changed to xlibsWrapper.
* texinfo is necessary for Makeinfo.
* e2fsprogs was recenty fixed on nicpkgs to include fuse2fs to mount
serenity images without root access but it needed some configuration.
Moves the nix script to setup the build environment from Documentation
into the Toolchain as a callable script. I also modified the script
to accept a "pkgs" argument to make it easy to override the nixpkgs
version from the command-line when calling the script.
Make sure that we set CMAKE_NM, it's possible that some version of
CMake could choose a host nm binary instead of the ones we just built.
It's unlikely that host nm will understand our .dyn.relr segments unless
it's from binutils 2.38 or higher, so it might complain.
I noticed after upgrading my machine that the QEMU is no longer building
due to GCC enabling `-fcf-protection` by default, even for targets that
don't support it.
The included patch came from the QEMU development list, but hasn't be
included in any patch releases at the time of writing.
https://lore.kernel.org/all/20220208211937.79580-1-vineetg@rivosinc.com/
Until QEMU patches, lets fix it on our end by patching before we build.
This commit adds support for building the SerenityOS userland with the
new [mold linker].
This is not enabled by default yet; to link using mold, run the
`Toolchain/BuildMold.sh` script to build the latest release of mold, and
set the `ENABLE_MOLD_LINKER` CMake variable to ON. This option relies on
toolchain support that has been added just recently, so you might need
to rebuild your toolchain for mold to work.
[mold linker]: https://github.com/rui314/mold
This hash format offers faster symbol lookup than the System V hash.
We've been using it in all our shared libraries for a long time, but did
not have it enabled by default in our toolchain, so ports couldn't make
use of it.
Before this change, our dynamic linker's global constructor handler
relied on the GNU linker implicitly including the content of `.ctors`
section inside `.init_array`. The mold linker does not do this, so
global constructors would fail to be called in the mold-built userland.
There is no point in sticking to `.ctors`, as most other systems already
use the superior `.init_array` scheme. This commit changes the kernel
linker script to not discard this new section, and enables it by default
in our toolchain.
Although we handle it in the linker spec file, gcc will actually reject
this argument unless it's also enabled in the option file.
CMake adds this flag if the minimum required version is 3.3 or less (see
CMP0065), so old projects would fail to compile because of this
unrecognized option.
We erroneously appended ".so" after the base name for the library,
so we ended up checking for the existence of e.g. `libc.so.so`,
which obviously didn't exist, so we overwrote the existing libraries
when we rebuilt the toolchain.
Our build of LLVM's objcopy now supports the single missing feature
(--update-section) that previously forced us to use the one from GNU
Binutils. This means that there is no reason anymore to build Binutils
alongside LLVM's tools.
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.
Discord user aesophor pointed out that the GCC toolchain fails to build
on macOS, and traced the issue back to 41ea37f2, which is the latest
change to `gcc.patch`. Similarly, when I tried to run BuildIt.sh in the
`--dev` mode, `git apply` complained about the patch being malformed.
I regenerated the patch by manually applying the changes of 41ea37f2 on
top of a known good GCC source tree, and I sent the new file to them.
They reported that this fixed the build issue they were having.
I'm not even sure if this is a hack. However, we don't implement
memalign so it's necessary to tell GCC so it doesn't go looking for it
in their implementation of `new`
The `aarch64/t-aarch64` makefile fragment needs to be included for the
aarch64-specific parts of GCC to be built. Before 738e52da5, this was
done implicitly, but now it is not. This caused the following error when
building the toolchain: "aarch64-builtins.o: No such file or directory".
This property tells CMake that if a library is missing a SONAME field,
the link editor(s) we use will insert the full path to the library into
the binary. This is the behaivor of GNU ld compatible linkers, so let's
avoid that possiblity by telling CMake that it really doesn't want to
let the linker embed the full path to the lib. This is especially
important when cross-compiling things for ports and such, as the full
path to the lib will have absolutely nothing to do with the runtime path
By setting CMAKE_MODULE_PATH in the LLVM initial cache scripts, we can
make the "SerenityOS" CMAKE_SYSTEM_NAME usable in the builds of
compiler-rt, libunwind, libcxxabi and libcxx.
This simplifies some toolchain patches and brings the cross-compiler
patches closer to the Port's patches, and closer to something
upstreamable.
OpenBSD gzip does not have the -k flag to keep the original after
extraction. Work around this by copying the original gzip to the dest
and then extracting. A bit of a hack, but only needs to be done for the
first-time or rebuilds
OpenBSD provides crypt in libc, not libcrypt. Adjust if/else to check
for either and proceed accordingly
Remove outdated OpenBSD checks when building the toolchain
If we pass `-lgcc_s` explicitly to the linker, it will be added as a
dependency even if no functions are used from it. This behavior is not
consistent with other systems. GCC can already handle passing the
correct flags, so let's rely on that instead.
As an added benefit, we now get support for the `-static-libgcc` flag;
and `-static-pie` will no longer mistakenly link us against the dynamic
version of libgcc.
No toolchain rebuild is required.
If we have the LLVM port installed, CMake might pick up some of the
tools installed as part of it (`llvm-ar`, `llvm-strip`, etc.) instead of
the ones belonging to the host toolchain. These, of course, can't be run
on the host platform, so builds would eventually fail. This made it
impossible to rebuild the LLVM toolchain.
We now set these variables explicitly when compiling the LLVM runtime
libraries in order to avoid this issue.
This will come in handy if we want to use the LLVM port with a GNU host
compiler.
As of version 13, libc++ uses `__attribute__((using_if_exists))` to
import global LibC functions into the `std` namespace, which allows some
symbols to be absent. GCC does not support this attribute, so it fails
to build libc++ due to some obscure `wchar.h` functions. This means that
cross-compiling libc++ is not possible; and on-target builds would be
tedious, so we'll be better off using the toolchain's `libstdc++`.
The goal of these more recent additions to the Dockerfile is to provide
a working copy of SerenityOS with the toolchain prebuilt. To me, these
additions feel misplaced:
- The toolchain is built assuming the i686 architecture, which may not
be what you want.
- You get a shallow clone of the project limiting you in your abilities
to navigate through the project's history or bisect.
- There's this awkward directory structure of `/serenity/serenity-git`
and `/serenity/out`.
The Dockerfile is immensely useful for building SerenityOS in a
containerized environment, separate from the host's environment. If we
want to automate builds, we can always use CI or extend this image to
do so. For now, let's remove the `git clone` and associated actions.
Fixes#9310.
If we want to use clang-tidy on the codebase, we'll need to build
clang-tidy from an LLVM that has been patched and built with Serenity
cross-compilation support.
Serenity defines a protected range of memory that must not be mmapped,
and is apparently reserved for kernel tasks. In this case, the protected
range is anything below 0x800000.
However, in its default setting, binutils chooses the memory address
0x400000 as the mapping address for executables that do not have PIE
enabled, resulting in mmap being unable to map the file unless the load
address has been overwritten at link time or if it's a PIE.
To mitigate this, move the default base address somewhere outside of
that range (and preferably not anywhere close near the beginning of the
useable virtual memory space, to avoid running into it during sequential
allocations).
We were previously using TRY_COMPILE_TARGET_TYPE to bypass the compiler
check at the beginning of the CMake build, since we don't have LibC
available and therefore can't link at that point.
However, this breaks a lot of assumptions in try_compile when it comes
to library checks. While this was the main idea behind our usage of the
flag, it also has some really nasty side effects when software wants
to find out what library a symbol is in.
Instead, just manually tell CMake that our compiler works as intended
and keep the target type setting at its default.
