* Support mips64 - write correct pc register width on uc_emu_start
* Convert to UC_MODE_MIPS64
* Correctly select MIPS64 CPU model
* Simple 64-bit test - check it doesn't crash
* lint
* Comment
* Comment
* Add offset when indexing cpu model, makes tests work on older python
* Move test
* add PC check to test
* Fix test - add python version check
* Use RegressTest method for assert
Rationale: Previouly, Unicorn uses several hacks to pretend it supports
floating point instructions while not properly setting up something
like CPU features. Therefore, once related registers like CR4 is reset,
the hacks stop working and UC_ERR_INSN_INVALID is thrown. Setting the default
model to a CPu that has basical floating point support should have the
minimal break changes.
This code was commented out since 2021, but by default, the error
codewas initialized to `UC_REG_OK`, so there was no error returned
untila result, any write to `UC_ARM_REG_C1_C0_2` returned an error.
Unlike some other architectures, RISC-V does not expose the current
privilege mode in any architecturally-defined register. That is intentional
to make it easier to implement virtualization in software, but a Unicorn
caller operates outside of the emulated hart and so it can and should be
able to observe and change the current privilege mode in order to properly
emulate certain behaviors of a real CPU.
The current privilege level is therefore now exposed as a new
pseudo-register using the name "priv", which matches the name of the
virtual register used by RISC-V's debug extension to allow the debugger
to read and change the privilege mode while the hart is halted. Unicorn's
use of it is conceptually similar to a debugger.
The bit encoding of this register is the same as specified in RISC-V Debug
Specification v1.0-rc3 Section 4.10.1. It's defined as a "virtual"
register exposing a subset of fields from the dcsr register, although here
it's implemented directly inside the Unicorn code because QEMU doesn't
currently have explicit support for the CSRs from the debug specification.
If it supports "dcsr" in a future release then this implementation could
change to wrap reading and writing that CSR and then projecting the "prv"
and "v" bitfields into the correct locations for the virtual register.
Some structs, specically CPUARMState is 16-bytes aligned.
This causes segment fault because gcc tends to vectorize
the assignment of the struct with infamous movaps tricks.
Without this patch, we fail on manylinux with 2.17 glibc
in release mode in i686.
qemu_memalign will ensure the alignment across platforms.
