Remove all functions with platform #if's from fenv, and
add arch dependent implementations instead. The build
system now selects the implementation based on the platform.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
When we run directly the dynamic loader, we shouldn't rely on the passed
program path to be run, but rather on whether the main program fd number
is not -1, because the kernel will set it to a non-negative number if it
exists.
To test that the heuristic is working correctly, the /usr/lib/Loader.so
file can be copied to /tmp/Loader.so and then be invoked from that path.
If the user runs /usr/lib/Loader.so and pass a second string to argv, we
will try to run it as if it was running that program without invoking
the dynamic loader explicitly.
This makes CMake pass `-fpie` instead of `-fpic` to the compiler when
building the Kernel and userland *executables*. This allows the compiler
to make certain optimizations based on the fact that the code will be
used in an executable, such as not having to emit `.localalias` symbols.
This leads to a 450 KiB decrease in the size of the Kernel binary.
This is a prerequisite for upstreaming our LLVM patches, as our current
hack forcing `-ftls-model=initial-exec` in the Clang driver is not
acceptable upstream.
Currently, our kernel-managed TLS implementation limits us to only
having a single block of storage for all thread-local variables that's
initialized at load time. This PR merely implements the dynamic TLS
interface (`__tls_get_addr` and TLSDESC) on top of our static TLS
infrastructure. The current model's limitations still stand:
- a single static TLS block is reserved at load time, `dlopen()`-ing
shared libraries that define thread-local variables might cause us to
run out of space.
- the initial TLS image is not changeable post-load, so `dlopen()`-ing
libraries with non-zero-initialized TLS variables is not supported.
The way we repurpose `ti_module` to mean "offset within static TLS
block" instead of "module index" is not ABI-compliant.
Since https://reviews.llvm.org/D131441, libc++ must be included before
LibC. As clang includes libc++ as one of the system includes, LibC
must be included after those, and the only correct way to do that is
to install LibC's headers into the sysroot.
Targets that don't link with LibC yet require its headers for one
reason or another must add install_libc_headers as a dependency to
ensure that the correct headers have been (re)installed into the
sysroot.
LibC/stddef.h has been dropped since the built-in stddef.h receives
a higher include priority.
In addition, string.h and wchar.h must
define __CORRECT_ISO_CPP_STRING_H_PROTO and
_LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS respectively in order to tell
libc++ to not try to define methods implemented by LibC.
If we don't set FP and LR to 0, the Kernel might not stop generating
backtraces when it reaches `_start`'s stack frame, and might continue by
reading garbage memory instead. This leads to a kernel panic, as SafeMem
access faults aren't handled properly in the AArch64 kernel yet.
We might want to ensure that the kernel zeroes out all registers when a
new process is created.
The code would access the __stack_chk_guard variable in main.cpp and
LibELF/Relocation.cpp before the loader was able to relocate itself, so
this commit disable the stack protector for the aarch64 build to make
sure that no accesses to __stack_chk_guard are inserted.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
The shared parts are now firmly compiled into LibC instead of being
defined as a static library and then being copied over manually.
The non-shared ("local") parts are kept as a static library that is
linked into each binary on demand.
This finally allows us to support linking with the -fstack-protector
flag, which now replaces the `ssp` target being linked into each binary
accidentally via CMake.
There's still a GLOB pattern for the LibC assembly files, but orgaizing
the patterns to use ${SERENITY_ARCH} instead of a big if-else chain
makes the patterns easier to understand.
This lets us remove a glob pattern from LibC, the DynamicLoader, and,
later, Lagom. The Kernel already has its own separate list of AK files
that it wants, which is only a subset of all AK files.
Note that as part of this commit semaphore.cpp is excluded from the
DynamicLoader, as the dynamic loader does not build with pthread.cpp
which semaphore.cpp uses.
Most of the string.h and wchar.h functions are implemented quite naively
at the moment, and GCC's pattern recognition pass might realize what we
are trying to do, and transform them into libcalls. This is usually a
useful optimization, but not when we're implementing the functions
themselves :^)
Relevant discussion from the GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
This prevents the infamous recursive `strlen`.
A more proper fix would be writing these functions in assembly. That
would likely give a small performance boost as well ;)
This option sets -fprofile-instr-generate -fcoverage-mapping for Clang
builds only on almost all of Userland. Loader and LibTimeZone are
exempt. This can be used for generating code coverage reports, or even
PGO in the future.
This commit addresses the following shortcomings of our current, simple
and elegant memset function:
- REP STOSB/STOSQ has considerable startup overhead, it's impractical to
use for smaller sizes.
- Up until very recently, AMD CPUs didn't have support for "Enhanced REP
MOVSB/STOSB", so it performed pretty poorly on them.
With this commit applied, I could measure a ~5% decrease in `test-js`'s
runtime when I used qemu's TCG backend. The implementation is based on
the following article from Microsoft:
https://msrc-blog.microsoft.com/2021/01/11/building-faster-amd64-memset-routines
Two versions of the routine are implemented: one that uses the ERMS
extension mentioned above, and one that performs plain SSE stores. The
version appropriate for the CPU is selected at load time using an IFUNC.
LibTimeZone will be needed directly within LibC for functions such as
localtime(). This change adds LibTimeZone directly within LibC, so that
LibTimeZone isn't its own .so library anymore.
LibTimeZone itself is compiled as an object library to make it easier to
give it generator-specific compilation flags.
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.
Replace the old logic where we would start with a host build, and swap
all the CMake compiler and target variables underneath it to trick
CMake into building for Serenity after we configured and built the Lagom
code generators.
The SuperBuild creates two ExternalProjects, one for Lagom and one for
Serenity. The Serenity project depends on the install stage for the
Lagom build. The SuperBuild also generates a CMakeToolchain file for the
Serenity build to use that replaces the old toolchain file that was only
used for Ports.
To ensure that code generators are rebuilt when core libraries such as
AK and LibCore are modified, developers will need to direct their manual
`ninja` invocations to the SuperBuild's binary directory instead of the
Serenity binary directory.
This commit includes warning coalescing and option style cleanup for the
affected CMakeLists in the Kernel, top level, and runtime support
libraries. A large part of the cleanup is replacing USE_CLANG_TOOLCHAIN
with the proper CMAKE_CXX_COMPILER_ID variable, which will no longer be
confused by a host clang compiler.
GCC implements `fputc`, `fputs` and `fwrite` as builtin functions, whose
`FILE*` argument is implicitly marked `__attribute__((nonnull))`. This
causes our `VERIFY(stream)` statements to be removed. This does not
happen with Clang, as they do not use the `nonnull` attribute in this
way.
We have had these for quite a while, but we didn't compile them, and
used GCC's version instead. Clang does not come with these, so we have
to provide our own implementation.
Our implementation follows what `musl` and `FreeBSD` do, so this should
work fine, even if documentation can hardly be found for them.
The System V ABI for both x86 and x86_64 requires that the stack pointer
is 16-byte aligned on entry. Previously we did not align the stack
pointer properly.
As far as "main" was concerned the stack alignment was correct even
without this patch due to how the C++ _start function and the kernel
interacted, i.e. the kernel misaligned the stack as far as the ABI
was concerned but that misalignment (read: it was properly aligned for
a regular function call - but misaligned in terms of what the ABI
dictates) was actually expected by our _start function.
Using LibELF to do the initial relocations doesn't work when building
SerenityOS with Clang. We seem to be accessing a global symbol that
hasn't been relocated yet somewhere along the path to
ELF::DynamicObject::create().
Take Kernel/UBSanitizer.cpp and make a copy in LibSanitizer.
We can use LibSanitizer to hold other sanitizers as people implement
them :^).
To enable UBSAN for LibC, DynamicLoader, and other low level system
libraries, LibUBSanitizer is built as a serenity_libc, and has a static
version for LibCStatic to use. The approach is the same as that taken in
Note that this means now UBSAN is enabled for code generators, Lagom,
Kernel, and Userspace with -DENABLE_UNDEFINED_SANTIZER=ON. In userspace
however, UBSAN is not deadly (yet).
Co-authored-by: ForLoveOfCats <ForLoveOfCats@vivaldi.net>
This links the dynamic linker against libgcc.a instead of having
our own copy of the math functions.
For now we need to specify -fbuilding-libgcc as a hack to work
around a bug with the -nodefaultlibs flag. Once everyone is on
the latest toolchain version this can be removed.
math.cpp: In function 'int64_t __moddi3(int64_t, int64_t)':
math.cpp:168:13: error: 'r' may be used uninitialized
[-Werror=maybe-uninitialized]
168 | return ((int64_t)r ^ s) - s; // negate if s == -1
| ^~~~~~~~~~
