Since `gethostbyname()` can't fail because of memory-related issues, it
has no way of representing a memory-related failure. We therefor use
`NO_RECOVERY` to represent a memory-related failure as well
as its normal name server related failures.
These functions are required for the `perl5` port's random function to
operate correctly. As a bonus, this allows us to remove a nasty patch
that replaces `drand48` with `random`.
These syscalls are not necessary on their own, and they give the false
impression that a caller could set or get the thread name of any process
in the system, which is not true.
Therefore, move the functionality of these syscalls to be options in the
prctl syscall, which makes it abundantly clear that these operations
could only occur from a running thread in a process that sees other
threads in that process only.
This is a minimal set of changes to allow `serenity.sh build riscv64` to
successfully generate the build environment and start building. This
includes some, but not all, assembly stubs that will be needed later on;
they are currently empty.
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.
Now that support for 32-bit x86 has been removed, we don't have to worry
about the top half of `off_t`/`u64` values being chopped off when we try
to pass them in registers. Therefore, we no longer need the workaround
of pointers to stack-allocated values to syscalls.
Note that this changes the system call ABI, so statically linked
programs will have to be re-linked.
Otherwise, if an application defines its own macros, the implementations
get messed up. This way we redefine those macros if they're set.
This fixes the PHP port build.
tl;dr: This fixes deadlocks that would occur in most applications in
Serenity when SMP was enabled.
As an optimization to `pthread_mutex_unlock()`, if only one thread
holds a mutex lock, it will avoid calling `futex()` to wake, since no
threads are actually waiting in `futex()`.
If a thread manages to synchronously unlock and relock the same mutex,
the state will be set to indicate that a wake is not needed, regardless
of whether any other threads are waiting for the lock. This should be
fine, as a thread that is waiting will set the mutex to needing a wake
and check if it is unlocked to unblock itself in the same atomic
operation.
However, when `pthread_mutex_lock()` was called with only one thread
holding the mutex lock, instead of telling `futex()` to atomically
sleep the thread if the state is set to indicate that a wake is
needed, the first wait would check if the state was set to indicate a
wake was _not_ needed. This means it is possible for the call to
`futex()` to wait when any subsequent call to `pthread_mutex_unlock()`
would not call `futex()` to wake, causing it to wait forever.
After that, any other thread that tries to take the lock will see that
the lock is taken and also `futex()` wait. Despite the fact that these
other threads would set the state to needing a wake, there will be no
unblocked thread holding the lock to actually wake them.
By making it wait only if the state indicates to other threads that a
wake is needed, heavily contended mutexes should no longer cause
deadlocks. Most applications would encounter these deadlocks due to the
mutex used by `malloc()`, some sooner than others. The worst offenders
(other than Ladybird) were most likely VideoPlayer and SoundPlayer.
Isn't
"expected struct timeval *, but argument is of type struct timeval *"
a fun error message? C considers a 'struct foo' mentioned inside a
function argument to be a distinct type from 'struct foo' declared on
the global level, but only if the in-function definition comes first. So
we need to ensure that struct timeval is declared (either fully, or
forward-declared) before we declare select() and pselect(). This was
taken care of by including <sys/time.h>, but
https://github.com/SerenityOS/serenity/pull/20044 made it so that
<sys/time.h> itself includes <sys/select.h>. So if the user's program
includes <sys/time.h> (before possibly including <sys/select.h>), then
<sys/select.h>'s include of <sys/time.h> will turn into a no-op (since
<sys/time.h> is already being included), yet there will not have been a
struct timeval definition yet, and we'd get the fun error message.
Fix this by including <Kernel/API/POSIX/sys/time.h> instead of
<sys/time.h>
Commit cccb6c7287 has moved some function
definitions into complex.h. The functions were marked inline, but not
static, so a symbol definition was emited for them in any compilation
unit that included complex.h. If multiple such compilation units get
linked into the same binary, we get a duplicate symbol error.
Fix this by declaring the functions static inline.
`memcpy()` and `memmove()` are functionally equivalent if the source and
destination memory regions do not overlap. If this is the case, we
should prefer `memcpy()` as it's implemented in a simpler and faster
way. As our `memcpy()` starts copying from the lowest address first,
relaxing a `memmove()` call to `memcpy()` is safe if the destination:
- starts at a lower address than the source
- starts at a higher address than the source's end
This is a preparation before we can create a usable mechanism to use
filesystem-specific mount flags.
To keep some compatibility with userland code, LibC and LibCore mount
functions are kept being usable, but now instead of doing an "atomic"
syscall, they do multiple syscalls to perform the complete procedure of
mounting a filesystem.
The FileBackedFileSystem IntrusiveList in the VFS code is now changed to
be protected by a Mutex, because when we mount a new filesystem, we need
to check if a filesystem is already created for a given source_fd so we
do a scan for that OpenFileDescription in that list. If we fail to find
an already-created filesystem we create a new one and register it in the
list if we successfully mounted it. We use a Mutex because we might need
to initiate disk access during the filesystem creation, which will take
other mutexes in other parts of the kernel, therefore making it not
possible to take a spinlock while doing this.
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.
This is needed to avoid including LibC headers in Lagom builds.
Unfortunately, we cannot rely on the build machine to provide a
fully POSIX-compatible ELF header for Lagom builds, so we have to
use our own.
libc++ disallows including LibC's complex.h in C++ mode. This means that
a C++ file cannot expect LibC's complex.h to be included, and thus
cannot use c-prefixed complex number functions. As a result,
complex.cpp is broken when libc++ has a higher include priority
than LibC.
A check for __cplusplus has been added to complex.h to warn users of
toolchains that don't use libc++.
Change the name and return type of
`IPv6Address::to_deprecated_string()` to `IPv6Address::to_string()`
with return type `ErrorOr<String>`.
It will now propagate errors that occur when writing to the
StringBuilder.
There are two users of `to_deprecated_string()` that now use
`to_string()`:
1. `Formatted<IPv6Address>`: it now propagates errors.
2. `inet_ntop`: it now sets errno to ENOMEM and returns.
Depending on stack values being correctly and deterministically
overwritten was a bit too optimistic, to be honest. This new logic uses
a value on the heap.
Dr. POSIX says:
Although the space used by string is no longer used once a new
string which defines name is passed to putenv(), if any thread in
the application has used getenv() to retrieve a pointer to this
variable, it should not be freed by calling free(). If the changed
environment variable is one known by the system (such as the locale
environment variables) the application should never free the buffer
used by earlier calls to putenv() for the same variable.
Applications _should_ not free the data passed to `putenv`, but they
_could_ in practice. I found that our Quake II port misbehaves in this
way, but does not crash on other platforms because glibc/musl `putenv`
does not assume that environment variables are correctly formatted.
The new behavior ignores environment variables without a '=' present,
and prevents excessively reading beyond the variable's name if the data
pointed to by the environment entry does not contain any null bytes.
With this change, our Quake II port no longer crashes when switching
from fullscreen to windowed mode.
That's what this class really is; in fact that's what the first line of
the comment says it is.
This commit does not rename the main files, since those will contain
other time-related classes in a little bit.
GCC 13 produces the following true positive warnings:
- `-Wredundant-move` when trying to move `result->tooltip()`, which
is a const reference in `Assistant/main.cpp`
- `-Wuse-after-free` when freeing an environment variable before
removing it from `s_malloced_environment_variables`
- `-Wdangling-pointer` when storing an AST node's `this` pointer to the
interpreter's node stack in LibJS. This is not actually an issue, as
it is popped when the scope ends, but GCC has no way of telling this.
This is the AArch64 equivalent of `R_X86_64_IRELATIVE`, which specifies
a symbol whose address is determined by calling a local IFUNC resolver
function.
To be able to port c-ares the IN6_IS_ADDR_V4COMPAT and
various macros of the form IN6_IS_ADDR_MC_XX_LOCAL were added
as well as the IN_CLASS{A,B} macros
Instead of storing x86_64 register names in `SC_create_thread_params`,
let the Kernel figure out how to pass the parameters to
`pthread_create_helper`.
