The ram_offset allocator searches the smalest gap in the ram_offset address space.
This is slow especialy in combination with many allocation (i.e. snapshots). When
it is known that there is no gap, this is now optimized.
Uses Copy on Write to make it posible to restore the memory state after a snapshot
was made. To restore all MemoryRegions created after the snapshot are removed.
target/i386: Verify memory operand for lcall and ljmp
These two opcodes only allow a memory operand.
Lacking the check for a register operand, we used the A0 temp
without initialization, which led to a tcg abort.
Maven is now used to update the constants, build the Java code, call make to
build the native library, and run all the tests. I have removed the "install"
and "uninstall" targets; instead, the expectation will be that the JNI library
will be placed somewhere on java.library.path and the JAR file will be used as
usual (e.g. in a downstream Maven project, or placed on the classpath of your
project).
Since Maven is now running our tests, this eliminates the need to bundle test
dependencies in `testdep`, and makes the project structured more like a typical
Java project.
Unsigned BigIntegers are a bit more ergonomic, particularly for bitwise
operations. reg_write still accepts negative BigIntegers (and will automatically
sign extend them), but reg_read will produce unsigned BigIntegers by default.
This brings the Java API up to par with Python feature-wise and substantially
simplifies the hook implementation, enabling proper bounds-checked hooks.
The rewrite strives for compatibility with the previous API, but there are some
breaking changes. It is possible to push closer to full backwards compatibility
if required, at the cost of reintroducing some of the suboptimal designs. Here
are the main points of breakage:
- ReadHook and WriteHook are gone, replaced simply by MemHook. Hooking valid
memory accesses now requires a type parameter. This enables fetch and
read-after hooks with a unified API and a single callback object.
- mem_read now takes an int, not a long. We are unable to allocate more than 2GB
in a single request anyway (Java limitation).
- Instruction hooks now require specifying the instruction explicitly, instead
of guessing based on the hook type. This is necessary to distinguish
sysenter/syscall and ARM64 mrs/msr/sys/sysl, without excessively bloating the
library with redundant hook types. Bounds must also be specified, to support
bounds-checked instruction hooks.
- Reading object-type registers (any register larger than 64 bits, or registers
with special formats) requires a second argument to reg_read. This allows us
to provide a fast reg_read that returns a long for the common cases, while
still supporting a more general reg_read for other registers.
- mem_map_ptr is rewritten to take a *direct* java.nio.Buffer, which enables
many more use cases than a simple byte array, and improves performance (a
byte array cannot really be used as a mapped buffer without GC-pinning it,
which hurts the GC performance).
- Context handling API is redesigned to be safer and more object-oriented.
A lot of bugs are fixed with this implementation:
- Unicorn instances can be properly garbage-collected, instead of hanging around
forever in the Unicorn.unicorns table.
- Hooks no longer fire outside of their bounds (#1164), and in fact, hook bounds
are properly respected (previously, all hooks were just registered globally to
all addresses).
- Hooks are substantially faster, as they are now dispatched directly via a
single method call rather than being indirected through invokeCallbacks.
- Loading vector registers works now, rather than crashing the VM (#1539).
Several features are now enabled in the Java implementation:
- All of the current ctl_* calls are implemented.
- mmio_map is implemented.
- New virtual TLB mode is implemented.
- reading/writing Context registers is implemented.
- New hook types are added: TcgOpcodeHook, EdgeGeneratedHook,
InvalidInstructionHook, TlbFillHook, and the instruction hooks Arm64SysHook,
CpuidHook.
- All known special registers are supported.
RISCV FP registers are 64-bit in size, even in 32-bit mode, because they can
hold doubles. The test even uses the double-precision instruction fmv.d. Thus,
the reads should be reading 64-bit registers.
Eli