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.
libc++ uses a Pthread condition variable in one of its initialization
functions. This means that Pthread forwarding has to be set up in LibC
before libc++ can be initialized. Also, because LibPthread is written in
C++, (at least some) parts of the C++ standard library have to be linked
against it.
This is a circular dependency, which means that the order in which these
two libraries' initialization functions are called is undefined. In some
cases, libc++ will come first, which will then trigger an assert due to
the missing Pthread forwarding.
This issue isn't necessarily unique to LibPthread, as all libraries that
libc++ depends on exhibit the same circular dependency issue.
The reason why this issue didn't affect the GNU toolchain is that
libstdc++ is always linked statically. If we were to change that, I
believe that we would run into the same issue.
Before this change, we would generate the static C library by running
the command `ar -qcs` to collect the various `*.o` files into a single
archive.
The `q` option stands for "quick append", which simply appends new files
to the archive, without replacing any pre-existing entries for the same
file. The problem with this is obvious: each LibC rebuild would add
approximately 1 MB (the size of a cleanly built libc.a) to the size of
the file. It got so bad on my machine that the total file size ended up
being 3 gigabytes.
Note that this did not affect the GNU toolchain, because, as the `ar(1)`
manpage says:
> Note - GNU ar treats the command qs as a synonym for r - replacing
> already existing files in the archive and appending new ones at the
> end.
This was required before commit 5f724b6ca1
when we were building LibC before libstdc++ headers were available in
the sysroot. However as noted in that commit, we never actually needed
to be building LibC before libstdc++, so we can go ahead and remove this
ancient hack.
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.
This adds a stub for fnmatch and the following defined values:
- FNM_PATHNAME
- FNM_NOESCAPE
- FNM_PERIOD
- FNM_FILE_NAME
- FNM_LEADING_DIR
- FNM_CASEFOLD
- FNM_EXTMATCH
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.
The POSIX C regex functions are expected to live in the C standard
library, but Serenity split off its regex library into LibRegex. Make a
compromise by implementing stub forwarders for the C regex library that
load libregex.so and call the real implementation.
This is needed for ports that expect these C functions to be available
inside the standard C library without introducing a strong coupling
between LibC and LibDl or LibRegex. The non-standard Serenity C++ regex
API still lives inside LibRegex as before.
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.
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>
In a1720eed2a I added this new test,
but missed that there were already some "unit tests" for LibC over
in Userland/Tests/LibC. So lets unify these two locations.
GCC will insert various calls to pthread functions when compiling
C++ code with static initializers, even when the user doesn't link
their program against libpthread explicitly.
This is used to make static initializers thread-safe, e.g. when
building a library that does not itself use thread functionality
and thus does not link against libpthread - but is intended to
be used with other code that does use libpthread explicitly.
This makes these symbols available in libc.
Instead GCC should be used to automatically link against crt0
and crt0_shared depending on the type of object file that is being
built.
Unfortunately this requires a rebuild of the toolchain as well
as everything that has been built with the old GCC.
Previously, libc.a contained undefined symbols from ssp and libsystem,
which caused static compilation to fail.
We now generate libc.a with a custom CMake rule that combines all
object files from libc, ssp and libsystem to form libc.a
Closes#5758.
Instead of having a special case in the dynamic loader where we ignore
TM-related GCC symbols, just stub them out in LibC like we already do
for various other things we don't support.
This removes some hard references to the toolchain, some unnecessary
uses of an external install command, and disables a -Werror flag (for
the time being) - only if run inside serenity.
With this, we can build and link the kernel :^)
This required a bit of rearchitecture, as pthread_atfork() required a
mutex, and duplicating a mutex impl for it was silly.
As such, this patch moves some standalone bits of pthread into LibC and
uses those to implement atfork().
It should be noted that for programs that don't use atfork(), this
mechanism only costs two atomic loads (as opposed to the normal mutex
lock+unlock) :^)
This achieves two things:
- Programs can now intentionally perform arbitrary syscalls by calling
syscall(). This allows us to work on things like syscall fuzzing.
- It restricts the ability of userspace to make syscalls to a single
4KB page of code. In order to call the kernel directly, an attacker
must now locate this page and call through it.
