Previously, we would unconditionally build GDB from source for the
AArch64 toolchain. This commit makes it possible to use the system's
`gdb` binary if it supports the architecture, or `aarch64-elf-gdb` if
such a package is installed.
An `aarch64-elf-gdb` package will be available through Homebrew once
this PR is merged: https://github.com/Homebrew/homebrew-core/pull/127323
The latter is problematic as it may be contained in the username (e.g.
email address-like) and thus the $SRC_ROOT path. This would cause an
invalid sed command to be created, breaking both of these scripts.
aarch64 required this to successfully build, but the actual fix to that
is to just make sure that crtbeginS and crtendS get built as a part of
the toolchain.
This partially reverts commit c18c84dbfd.
Without this tag, executables that link libgcc_s.so.1, which is every
executable, end up with the host path to libgcc_s.so.1 as the path for
the dynamic dependency (DT_NEEDED) of the executable. By making sure
that the libgcc_s.so.1 shared object includes the DT_SONAME tag, the
path to libgcc_s.so.1 dynamic dependency will only contain the basename,
instead of the absolute host path.
Since we upstreamed CMake support for Serenity, we can use the Platform
files from upstream instead of keeping our local copy. While not added
in this commit, we can add patching capabilities for the platform files
similar to what we do for gdb, llvm, gcc, and binutils later.
This is necessary to build on MacOS. As discussed in #15530, Serenity
no longer appears to build on MacOS Ventura. This attempts to fix that
by enforcing it at the command level.
QEMU 7.1 was released on August 30th.
Release Notes: https://wiki.qemu.org/ChangeLog/7.1
The patch 'Toolchain/Patches/qemu-cf-protection-none.patch' (or similar)
has been upstreamed so it can be safely removed.
So far we've gotten away with using GCC 11 for Lagom and to compile the
toolchain, but via #15795 we discovered a compiler bug that has been
fixed in the latest version but would error the build with CI's GCC 11.
Time for an upgrade :^)
We already use ubuntu-22.04 images in most places, so this is pretty
straightforward. The only exception is Idan's self-hosted runner, which
uses Ubuntu Focal. LibJS should build fine with GCC 11, still.
I originally missed this while handling the upgrade to LLVM 15 (as it
only affects the on-serenity port), so the patch gets to be here with a
bit of a delay.
Co-Authored-By: sin-ack <sin-ack@users.noreply.github.com>
There was a typo in one of the spec files which resulted in us not
building softfp support for libgcc. Additionally we were missing flags
to build libgcc_s. This patch also makes sure we're not trying to
link against crtbeginS.o and crtendS.o. This is part of a larger effort
to at least get the userland to build at all.
Neither are we changing any of our documentation files, nor do we need
any of the documentation that is likely being built.
With macOS potentially removing makeinfo from the default Xcode lineup,
SerenityOS not being able to install it at all currently due to a lack
of perl, and it otherwise just being a dependency that has to be
installed to make the build system happy, lets just stub it out.
Nix (nixpkgs) have updated a while back how the e2fsprogs derivation
works and now fuse2fs wasnt being installed with it. It is now needed to
add a new derivation (package) to the dependency list: "fuse2fs". This
fixes the Meta/serenity.sh script not finding the fuse2fs binary for
rootless image building :^)
This is a preparation to check if our users find noticeable bugs in the
x86-64 target, before we can decide if we want to remove the i686 target
for good.
This keeps us from accidentally building toolchains that don't make it
through a clean build if we build them using a populated sysroot, as it
would otherwise detect libpthread and friends and try to pull them in
while LibC is not yet built.
Following the pattern for qemu, mold, and clang, we should install the
host ruby required to build the ruby port into its own install tree
rather than forcing it into the GNU compiler's bindir.
Following the pattern for qemu, mold, and clang, we should install the
host python required to build the python port into its own install tree
rather than forcing it into the GNU compiler's bindir.
Now that the lower pages can be unmapped and more of the virtual
address range is available to us, we can actually use the default
mapping address of x86_64 again.
This reverts commit 292398b585.
This shouldn't cause any breaking changes, so a toolchain rebuild is not
required.
As per Hendiadyoin's request, math errno is disabled by default, which
should enable some extra compiler optimizations in LibGL and LibSoftGPU
code that uses math functions heavily.
Co-Authored-By: Ali Mohammad Pur <mpfard@serenityos.org>
This release brings support for various C++23 constructs like `if
consteval` and multidimensional subscript operators. Vectorization is
now enabled for O2 too, and `-ftrivial-auto-var-init` has been added
which can help us find and prevent security issues coming from
uninitialized variables.
Toolchain/Patches/gcc.patch is now significanly smaller as some unused,
autoconf-generated code has been removed.
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".
