FixedArray now doesn't expose any infallible constructors anymore.
Rather, it exposes fallible methods. Therefore, it can be used for
OOM-safe code.
This commit also converts the rest of the system to use the new API.
However, as an example, VMObject can't take advantage of this yet,
as we would have to endow VMObject with a fallible static
construction method, which would require a very fundamental change
to VMObject's whole inheritance hierarchy.
When writing into a block via an O_DIRECT open file description, we
would first flush every dirty block *except* the one we're about to
write into.
The purpose of flushing is to ensure coherency when mixing direct and
indirect accesses to the same file. This patch fixes the issue by only
flushing the affected block.
Our behavior was totally backwards and could end up doing a lot of
unnecessary work while avoiding the work that actually mattered.
Since this function always returns a CacheEntry& (after potentially
evicting someone else to make room), let's call it "ensure" instead of
"get" to match how we usually use these terms.
These checks were added because macOS doesn't have `shadow.h`, so we
would end up including our own LibC's `shadow.h` when we built Lagom.
All inclusions of this header in our code base are now guarded by
`#ifndef AK_OS_BSD_GENERIC`, so these checks are now pointless.
In C++, a function declaration with an empty parameter list means that
the function takes no arguments. In C, however, it means that the
function takes an unspecified number of parameters.
What we did previously was therefore non-conforming. This caused a
config check to fail in the curl port, as it was able to redeclare
`rand` as taking an int parameter.
Add a unit test for each sample pdf file that currently exists in the
anon user's `~/Document/pdf` directory.
- linear.pdf
- non-linearized.pdf
- complex.pdf
Each test ensures that the pdf document is parsed and that the page
count is the expected one.
Previously, we linked LibCrypt against LibCrypto. This creates a
circular symbol dependency between LibCore, LibCrypto and LibCrypt.
LibCrypto uses Core::DateTime, LibCrypt uses Crypto::SHA2, and LibCore
uses crypt in Core::Account. The GNU toolchain massages the DT_NEEDED
lines of each library and applications that use each library such that
the Loader finds all the symbols as necessary. However, when using the
Clang toolchain, the circular library dependency is not as tolerated.
We get a symbol not found error in the Loader at runtime, and the app in
question crashes.
Now, we build the SHA2.cpp implementation file into LibCrypt using an
object library and `-fvisibility=hidden -fvisibility-hidden-inlines`.
This adds the implementation in a way that only creates STB_LOCAL
symbols and should avoid nasty ODR problems in the future.
An alternative approach to resolving this dependency would be to move
Core::DateTime to AK, or to make Crypto::ASN1::parse_utc_date return a
struct tm instead of a Core::DateTime. One of those approaches to
remove the LibCore dependency from LibCrypto should probabably be
investigated further in the future.
The net effect of removing this circular library dependency is that one
can now build and run the python3 port with the Clang toolchain :^)
The --enable-optimizations flag attempts to enable PGO. Profile-guided
optimization is great in general, but will not work at all when doing a
cross-compile. If there's a more fine-grained flag for generic
optimization levels that doesn't try to do PGO, we should enable that
instead. The flag also enables `-fno-semantic-interposition`, but our
GCC patches enable that by default for -fPIC anyway, so that's not
necessary.
Ports such as python require a distinction between host readelf and
target readelf. Set a toolchain-specific varaible for these, but be sure
save off the host readelf binary in case anyone needs it later.
This is part of allowing python to build with the Clang toolchain.
This allows building with the clang toolchain. We might consider a more
global patch in the future for this, it seems a lot of packages need
help to find /usr/local/lib.
By telling the libtool-related configure checks that the serenity
platform does in fact support shared libs, we can get a VERSYM-free
shared lib out of sqlite. This probably applies to other ports as well.
Suggested-by: Daniel Bertalan <dani@danielbertalan.dev>
When doing the last unref() on a listed-ref-counted object, we keep
the list locked while mutating the ref count. The destructor itself
is invoked after unlocking the list.
This was racy with weakable classes, since their weak pointer factory
still pointed to the object after we'd decided to destroy it. That
opened a small time window where someone could try to strong-ref a weak
pointer to an object after it was removed from the list, but just before
the destructor got invoked.
This patch closes the race window by explicitly revoking all weak
pointers while the list is locked.
LibUnicode no longer needs to generate a list of time zone names that it
parsed from metaZones.json. We can defer to the TZDB for a golden list
of time zones.
The IANA Time Zone Database contains data needed, at least, for various
JavaScript objects. This adds plumbing for a parser and code generator
for this data. The generated data will be made available by LibTimeZone,
much like how UCD and CLDR data is available through LibUnicode.
This function will be used by the time zone database parser. Move it to
the common utilities file, and rename it remove_path_if_version_changed
to be more generic.
This utility helps to dump the physical memory space from /dev/mem.
It supports both read(2) and mmap(2) on it so we could use mmap(2) for
fast dumping of the memory, or read(2) when we need to read unaligned
physical regions.
Although we can still consider this impossible to happen now, because
the mmap syscall entry code verifies that specified offset must be page
aligned, it's still a good practice to VERIFY we actually take a start
address as page-aligned in case of doing mmap on /dev/mem.
As for read(2) on /dev/mem, we don't map anything to userspace so it's
safe to read from whatever offset userspace specified as long as it does
not break the original rules of reading physical memory from /dev/mem.
So far we only had mmap(2) functionality on the /dev/mem device, but now
we can also do read(2) on it.
The test unit was updated to check we are doing it safely.
