The emulated aarch64 CPU does not contain the RNG cpu feature, so the
random number generator was not seeded. This commit adds a fallback to
use TimeManagement as a entropy source, such that get_good_random_bytes
works, which is needed for running the first userspace application on
aarch64.
This sets up the correct ThreadRegisters state when a process is
exec'ed, which happens when the first userspace application is executed.
Also changes Processor.cpp to get the stack pointer from the
ThreadRegisters.
This allows the function to be called from other translation units, in
particular this allows the CrashHandler.cpp file to be shared between
aarch64 and x86_64.
Setting the kernel_load_base variable caused backtracking to regress, so
to have proper backtracing the calculation of the symbol address in
KSyms.cpp needs to keep into account that the aarch64 kernel is linked
at a high virtual memory address.
When we execute in userspace, the exception level is EL0, so to handle
exceptions, such as interrupts, and syscalls, we need to add handlers to
vector_table.S. For now we only support running userspace applications
in AArch64 mode, so this commit only adds the handlers for that mode.
To detect instruction aborts, a helper to Registers.h is added, and used
in Interrupts.cpp. Additionally, the PageFault class gets a setter to
set the PageFaults m_is_instruction_fetch bool, and is also used in
Interrupts.cpp.
This reverts commit 4e0f85432a as the
ramdisk code is useful for the bring-up of the aarch64 port. Once the
kernel supports better ram-based filesystems, this code will be removed
again.
Functionality for checking image size in advance has been removed, as
this would require a SeekableStream and we now check for read errors
everywhere anyways.
This is a very new tag used for HDR content. The only files I know that
use it are the jpegs on https://ccameron-chromium.github.io/hdr-jpeg/
But they have an invalid ICC creation date, so `icc` can't process them.
(Commenting out the check for that does allow to print them.)
If the CIPC tag is present, it takes precedence about the actual data
in the profile and from what I understand, the ICC profile is
basically ignored. See https://www.color.org/events/HDR_experts.xalter
for background, in particular
https://www.color.org/hdr/02-Luke_Wallis.pdf (but the other talks
are very interesting too).
(PNG also has a cICP chunk that's supposed to take precedence over
iCCP.)
This isn't used by any mandatory tags, and it's not terribly useful.
But jpegs exported by Lightroom Classic write the 'tech' tag, and
it seems nice to be able to dump its contents.
signatureType stores a single u32 which for different tags with this
type means different things.
In each case, the value is one from a short table of valid values,
suggesting this should be a per-tag enum class instead of a
per-tag DistinctFourCC, per the comment at the top of DistincFourCC.h.
On the other hand, 3 of the 4 tables have an explicit "It is possible
that the ICC will define other signature values in the future" note,
which suggests the FourCC might actually be the way to go.
For now, just punt on that and manually dump the u32 in fourcc style
in icc.cpp and don't add any to_string() methods that return a readable
string based on the contents of these tables.
This is the type of namedColor2Tag, which is a required tag in
NamedColor profiles.
The implementation is pretty basic for now and only exposes the
numbers stored in the file directly (after endian conversion).
Though table wrappers are anonymous block containers (because
TableWrapper is inherited from BlockContainer) with no lines they
should not be skipped in block auto height calculation.
