Implement futimes() in terms of utimensat(). Now, utimensat() strays
from POSIX compliance because it also accepts a combination of a file
descriptor of a regular file and an empty path. utimensat() then uses
this file descriptor instead of the path to update the last access
and/or modification time of a file. That being said, its prior behavior
remains intact.
With the new behavior of utimensat(), `path` must point to a valid
string; given a null pointer instead of an empty string, utimensat()
sets `errno` to `EFAULT` and returns a failure.
Some ports linked against posix_memalign, but didn't use it, and others
used it if it was Available. So I decided to implement posix_memalign.
My implementation adds almost no overhead to regular mallocs. However,
if an alignment is specified, it will use the smallest ChunkedBlock, for
which aligned chunks exist, and simply use one of the chunks that is
aligned. If it cannot use a ChunkedBlock, for size or alignment reasons,
it will use a BigAllocationBlock, and return a pointer to the first
aligned address past the start of the block. This implementation
supports alignments up to 32768, due to the limitations of the
BigAllocationBlock technique.
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 ;)
The DisplayConnector class is meant to replace the FramebufferDevice
class. The advantage of this class over the FramebufferDevice class is:
1. It removes the mmap interface entirely. This interface is unsafe, as
multiple processes could try to use it, and when switching to and from
text console mode, there's no "good" way to revoke a memory mapping from
this interface, let alone when there are multiple processes that call
this interface. Therefore, in the DisplayConnector class there's no
implementation for this method at all.
2. The class uses a new real-world structure called ModeSetting, which
takes into account the fact that real hardware requires more than width,
height and pitch settings to mode-set the display resolution.
3. The class assumes all instances should supply some sort of EDID,
so it facilitates such mechanism to do so. Even if a given driver does
not know what is the actual EDID, it will ask to create default-generic
EDID blob.
3. This class shifts the responsibilies of switching between console
mode and graphical mode from a GraphicsAdapter to the DisplayConnector
class, so when doing the switch, the GraphicsManagement code actually
asks each DisplayConnector object to do the switch and doesn't rely on
the GraphicsAdapter objects at all.
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.
IFUNC is a GNU extension to the ELF standard that allows a function to
have multiple implementations. A resolver function has to be called at
load time to choose the right one to use. The PLT will contain the entry
to the resolved function, so branching and more indirect jumps can be
avoided at run-time.
This mechanism is usually used when a routine can be made faster using
CPU features that are available in only some models, and a fallback
implementation has to exist for others.
We will use this feature to have two separate memset implementations for
CPUs with and without ERMS (Enhanced REP MOVSB/STOSB) support.
Similarly to x86_64, Aarch64 is LP64, so its `uint64_t` type is
`unsigned long`.
Fixes a bunch of compiler warnings when compiling the LLVM runtime
libraries for the aarch64-pc-serenity target.
POSIX says that localtime should fail with EOVERFLOW if the result
cannot be represented, which is the case for most large (in absolute
value) time_t inputs, since they overflow (or underflow) tm_year, which
is an int. This patch introduces this functionality. Previously, tm_year
just overflowed (or underflowed) silently.
Incidentally, this partially fixes#12729 without solving the root
problem, which is that time_to_tm is linear in its input to determine
the number of years since epoch.
This means that the bash port mktime test no longer times-out in 60s,
but it still fails (faster) in some other place. Due to underlying issue
in the algorithm, the worst case inputs still take a couple of seconds
on my machine.
POSIX describes WCHAR_MIN and WCHAR_MAX in stdint.h(0P), while
wchar.h(0P) only says "as described in stdint.h".
As there isn't a trivial path of "may make visible", just move it to a
shared header and include it from both files.
On x86-64, `int64_t` is defined to be `long` (not `long long`) , so for
printing, the "l" format specifier has to be used instead of i686's
"ll".
A couple of these macros weren't updated when the x86-64 target was
added, so using them produced warnings like this:
> warning: format specifies type 'long long' but the argument has type
> 'int64_t' (aka 'long') [-Wformat]
>
> "DW_CFA_GNU_negative_offset_extended(%" PRId64 ")\n", offset);
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
This commit changes the macros to be correct for both architectures, and
reorders them to be consistent and adds a couple missing ones for the
sake of completeness.
If we break out of the loop before we attempt to allocate again,
then we double free the memory pointed to by `name_path`.
Found by Static Analysis: Sonar Cloud
Instead, to determine these values (both the pts name and tty name), use
other methods. For determining the new name of the allocated psuedo
terminal, use ioctl on a file descriptor we got after opening /dev/ptmx
with the TIOCGPTN option.
For determining the name of TTY, we enumerate both /dev/pts and /dev
directories to find matching inode number and matching device mode.
This ioctl operation will allow userspace to determine the index number
of a MasterPTY after opening /dev/ptmx and actually getting an internal
file descriptor of MasterPTY.
