| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
This makes binutils compatible with `./package.sh dev`, so that we can
regenerate patches more easily, and neatly stack (temporary) patches on
top.
|
|
|
|
|
|
|
|
|
|
This is essentially a no-op since we have our replacement linker script,
but if we can skip over that entirely, why not?
|
|
These are no longer required to use libc++ on Serenity
|
|
|
|
This removes the patch series 1/N comments, git version at the bottom of
the patch, and zeros out the original commit hash.
|
|
While we are at it, regenerate the patch and remove some outdated parts
of the description.
|
|
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 292398b5857d0104f7c33fdb5d79f45fe8b395dd.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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 version comes with general fixes and, more importantly, introduces
support for the packed RELR relocation format.
|
|
The `-fuse-ld=mold` flag was only added in the not-yet-released GCC 12.
Cherry-picked from the following upstream commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ad964f7eaef9c03ce68a01cfdd7fde9d56524868
|
|
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.
|
|
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".
|
|
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.
|
|
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.
|
|
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++`.
|
|
This will let us use `libgcc` for unwinding when we build the LLVM port
with the GNU toolchain.
|
|
The toolchain should work without setting `--sysroot` when we build
inside SerenityOS.
|
|
This option is already used by our GNU toolchain to avoid creating a
circular dependency between LibC and `lib(std)c++`.
|
|
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).
|
|
Now that we have `_aligned_malloc` and `_aligned_free`, we can finally
enable C++17 aligned allocation support.
|
|
This commit updates the Clang toolchain's version to 13.0.0, which comes
with better C++20 support and improved handling of new features by
clang-format. Due to the newly enabled `-Bsymbolic-functions` flag, our
Clang binaries will only be 2-4% slower than if we dynamically linked
them, but we save hundreds of megabytes of disk space.
The `BuildClang.sh` script has been reworked to build the entire
toolchain in just three steps: one for the compiler, one for GNU
binutils, and one for the runtime libraries. This reduces the complexity
of the build script, and will allow us to modify the CI configuration to
only rebuild the libraries when our libc headers change.
Most of the compile flags have been moved out to a separate CMake cache
file, similarly to how the Android and Fuchsia toolchains are
implemented within the LLVM repo. This provides a nicer interface than
the heaps of command-line arguments.
We no longer build separate toolchains for each architecture, as the
same Clang binary can compile code for multiple targets.
The horrible mess that `SERENITY_CLANG_ARCH` was, has been removed in
this commit. Clang happily accepts an `i686-pc-serenity` target triple,
which matches what our GCC toolchain accepts.
|
|
|
|
|
|
|
|
The gcc patch might not be completely correct, but at least the
toolchain completes building.
|
|
I locally modified Meta/serenity.sh to pass `--dev` to BuildIt.sh
in build_toolchain(). Then I ran `Meta/serenity.sh rebuild-toolchain`,
cd'd into Toolchain/Tarballs/binutils-2.37, `git add`ed unadded files in
`git status`, and then ran `git diff > ../../Patches/binutils.patch`.
Then I did the same for Toolchain/Tarballs/gcc-11.2.0 (and was careful
not to `git add` serenity-kernel.h, since that's created by
Toolchain/BuildIt.sh).
No behavior change. This just rewrites the patch like git writes it.
|
|
For now this is not a mandatory toolchain rebuild.
|
|
This contains all the bits and pieces necessary to build a Clang binary
that will correctly compile SerenityOS.
I had some trouble with getting LLVM building with a single command, so
for now, I decided to build each LLVM component in a separate command
invocation. In the future, we can also make the main llvm build step
architecture-independent, but that would come with extra work to make
library and include paths work.
The binutils build invocation and related boilerplate is duplicated
because we only use `objdump` from GNU binutils in the Clang toolchain,
so most features can be disabled.
|
|
Fixes #8377.
|
|
|
