This optimization has already been done in LibC's `assert.h`, which
Userland `VERIFY()` calls resolve to. We now use it in the kernel, but
with the nicer C++ *unlikely* attribute instead of `__builtin_expect`.
This tells the compiler to arrange the generated machine code so that
the error-free branches execute faster (e.g. fewer jumps, better cache
locality).
The Process::Handler type has KResultOr<FlatPtr> as its return type.
Using a different return type with an equally-sized template parameter
sort of works but breaks once that condition is no longer true, e.g.
for KResultOr<int> on x86_64.
Ideally the syscall handlers would also take FlatPtrs as their args
so we can get rid of the reinterpret_cast for the function pointer
but I didn't quite feel like cleaning that up as well.
Neither the kernel nor LibELF support loading libraries with larger
PT_LOAD alignment. The default on x86 is 4096 while it's 2MiB on x86_64.
This changes the alignment to 4096 on all platforms.
Userland faulted on the very first instruction before because the
PML4T/PDPT/etc. weren't marked as user-accessible. For some reason
x86 doesn't care about that.
Also, we need to provide an appropriate userspace stack segment
selector to iretq.
We regularily need to flush many rectangles, so instead of making many
expensive ioctl() calls to the framebuffer driver, collect the
rectangles and only make one call. And if we have too many rectangles
then it may be cheaper to just update the entire region, in which case
we simply convert them all into a union and just flush that one
rectangle instead.
This creates /dev/fbX devices for each physical output, owned by the
parent VirtIOGPU instance. This allows mapping and setting resolutions
independently for each output.
The types for asm_signal_trampoline and asm_signal_trampoline_end
were incorrect. They both point into the text segment but they're
not really functions.
This isn't particularly useful because by the time we've entered
init() the CPU had better support x86_64 anyway. However this shows the
CPU flag in System Monitor - even in 32-bit mode.
Without this the ProcessBase class is placed into the padding for the
ProtectedProcessBase class which then causes the members of the
RefCounted class to end up without the first 4096 bytes of the Process
class:
BP 1, Kernel::Process::protect_data (this=this@entry=0xc063b000)
205 {
(gdb) p &m_ref_count
$1 = (AK::Atomic<unsigned int, (AK::MemoryOrder)5> *) 0xc063bffc
Note how the difference between 'this' and &m_ref_count is less than
4096.
Currently, Kernel::Graphics::FramebufferConsole is written assuming that
the underlying framebuffer memory exists in physically contiguous
memory. There are a bunch of framebuffer devices that would need to use
the components of FramebufferConsole (in particular access to the kernel
bitmap font rendering logic). To reduce code duplication, framebuffer
console has been split into two parts, the abstract
GenericFramebufferConsole class which does the rendering, and the
ContiguousFramebufferConsole class which contains all logic related to
managing the underling vm object.
Also, a new flush method has been added to the class, to support devices
that require an extra flush step to render.
This fixes a bug that occurs when the controller's ports are not
(internally) numbered sequentially.
This is done by checking the bits set in PI.
This bug was found on bare-metal, on a laptop with 1 Port that
was reported as port 4.
Multiboot only supports ELF32 executables. This changes the build
process to build an ELF32 executable which has a 32-bit entry point,
but consists of mostly 64-bit code.
Since `m_storage` is already guaranteed to be correctly aligned for the
type, we can forgo specifying it for the entire class.
This fixes an error: previously, this would *force* the value type's
alignment on the entire class, which would try to make 1-byte aligned
ints with `KResultOr<bool>`. GCC somehow compiled this (probably just
ignored it), but this caused a build error with Clang.
Closes#8072
Clang requires that attributes declared using the bracketed
`[[attr_name]]` syntax come before those with
`__attribute__((attr-name))`.
This fixes a Clang build error.
This commit converts naked `new`s to `AK::try_make` and `AK::try_create`
wherever possible. If the called constructor is private, this can not be
done, so we instead now use the standard-defined and compiler-agnostic
`new (nothrow)`.
In standard C++, operators `new` and `new[]` are guaranteed to return a
valid (non-null) pointer and throw an exception if the allocation
couldn't be performed. Based on this, compilers did not check the
returned pointer before attempting to use them for object construction.
To avoid this, the allocator operators were changed to be `noexcept` in
PR #7026, which made GCC emit the desired null checks. Unfortunately,
this is a non-standard feature which meant that Clang would not accept
these function definitions, as it did not match its expected
declaration.
To make compiling using Clang possible, the special "nothrow" versions
of `new` are implemented in this commit. These take a tag type of
`std::nothrow_t` (used for disambiguating from placement new/etc.), and
are allowed by the standard to return null. There is a global variable,
`std::nothrow`, declared with this type, which is also exported into the
global namespace.
To perform fallible allocations, the following syntax should be used:
```cpp
auto ptr = new (nothrow) T;
```
As we don't support exceptions in the kernel, the only way of uphold the
"throwing" new's guarantee is to abort if the allocation couldn't be
performed. Once we have proper OOM handling in the kernel, this should
only be used for critical allocations, where we wouldn't be able to
recover from allocation failures anyway.
This rewrites the dbgputch and dbgputstr system calls as wrappers of
kstdio.h.
This fixes a bug where only the Kernel's debug output was also sent to
a serial debugger, while the userspace's debug output was only sent to
the Bochs debugger.
This also fixes a bug where debug output from one process would
sometimes "interrupt" the debug output from another process in the
middle of a line.
This adds a dbgputch() alongside dbgputstr() in kstdio.h. The function
already existed as the static function debugger_out(). It has now been
exposed to users of kstdio.h.
This adds just enough stubs to make the kernel compile on x86_64. Obviously
it won't do anything useful - in fact it won't even attempt to boot because
Multiboot doesn't support ELF64 binaries - but it gets those compiler errors
out of the way so more progress can be made getting all the missing
functionality in place.
When building the kernel for x86_64 the compiler injects calls to
__cxa_guard_acquire which depends on a bunch of pthread functions
we don't have in the kernel.
This fixes#8133.
Ext2FSInode::remove_child() searches the lookup cache, so if it's not
initialized, removing the child fails. If the child was a directory,
this led to it being corrupted and having 0 children.
I also added populate_lookup_cache to add_child. I hadn't seen any
bugs there, but if the cache wasn't populated before, adding that
one entry would make it think it was populated, so that would cause
bugs later.
The `File::can_write` mechanism lets us check that writes won't block,
meaning some bytes can be immediately written to the underlying device.
This means calling `File::write` in a situation where no data could be
written is a logic error, which we `VERIFY()` in `Process::do_write()`.
TTY, in particular, processes the write in 256-byte buffered chunks.
Previously, we would assert that none of these sub-writes returned zero.
This was a logic error, as this rejected some successful writes. For
example, if there was exactly enough free space in `SlavePty`'s internal
buffer for the previous sub-write to complete fully. This made it
impossible to perform writes larger than `SlavePty`'s internal buffer.
Note that it's not an issue if `on_tty_write` returns zero, as partial
writes are handled correctly by the `buffer.read_buffered` helper. We
won't spin in a loop trying to write to a full buffer.
Fixes#8090
If we have a VGA-capable graphics adapter that we support, we should
prefer it over any legacy VGA because we wouldn't use it in legacy VGA
mode in this case.
This solves the problem where we would only use the legacy VGA card
when both a legacy VGA card as well as a VGA-mode capable adapter is
present.
Steps to reproduce:
$ cat loop.c
int main() { for (;;); }
$ gcc -o loop loop.c
$ ./loop
Terminating this process wasn't previously possible because we only
checked whether the thread should be terminated on syscall exit.
This doesn't really matter in terms of writability for the kernel text
because we set up proper page mappings anyway which prohibit writing
to the text segment. However, this makes the profiler happy which
previously died when validating the kernel's ELF program headers.
Instead, try to create the device objects in separate static methods,
and if we fail for some odd reason to allocate memory for such devices,
just panic with that reason.
We now store the device descriptor obtained from the device
during enumeration in the device's object in memory instead
of exposing all of the different members contained within it.
