* arm64 python: Avoid nested class in insn hook for 10x hook speedup
Promote CpReg to a module-level class to address unnecessary performance
reduction. In a real-world use case tracing the emulation of real-world
machine code, this change reduces time spent in CpReg namedtuple
construction from 10% of overall time to below 1%, for a 10x speedup of
the insn hook itself, or a 10% overall speedup. Measured using
cProfile, python 3.13.
* upgrade distro to 22.04
* revert to 22.04 for now
* also revert for wheels
---------
Co-authored-by: mio <mio@lazym.io>
for glibc, if _GNU_SOURCE is defined, <time.h> will include <sys/timex.h>
but not for musl, so add "#include <sys/timex.h>"
although `man clock_adjtime` said "#include <sys/timex.h>", but it won't
work for glibc w/o "#include <time.h>", I don't known why yet.
PS it seems clock_adjtime is used nowhere?
Signed-off-by: Z. Liu <zhixu.liu@gmail.com>
* qemu/tcg: fix UC_HOOK_MEM_READ on aarch64.
Directly jump into the slow path when there is any hookmem enabled. This
fixes#1908.
Signed-off-by: Glenn Baker <glenn.baker@gmx.com>
* qemu/tcg: fix UC_HOOK_MEM_READ on ppc64.
Directly jump into the slow path when there is any hookmem enabled.
Signed-off-by: Glenn Baker <glenn.baker@gmx.com>
* qemu/tcg: check for UC_HOOK_MEM_READ_AFTER.
Use has_hookmem() helper to determine wether "slow-path" TLB read is
needed. Add this helper to x86 architecture as well so that to check for
all hookmem.
Signed-off-by: Glenn Baker <glenn.baker@gmx.com>
* qemu/tcg: factor out has_hookmem().
It's the same implementation for all architectures, so factor out
has_hookmem() into tcg_uc_has_hookmem().
Signed-off-by: Glenn Baker <glenn.baker@gmx.com>
---------
Signed-off-by: Glenn Baker <glenn.baker@gmx.com>
- Added fullMode input in workflow_dispatch
- Take decision whether to build either in debug or release mode and if to build for all python versions according to the commit message patterns
- Set proper artifact names
- Removed not needed steps
- Compacted some steps in order to leverage more the matrix feature
- Bumped cibuildwheel action to 2.22.0
- Run actual regress tests in place of sample scripts
- Specify optional test install in pyproject.toml with proper requirements
- Derive package version from git tags
- Add GENERATORS env var support in setup.py to specify cmake generator and minor refactoring
- Minor cleanup/refactoring for the regress test suite
- Marked some regress tests with skipIf to skip them in case of old python versions
- Marked some failing regress tests to be checked with skipIf
* Python binding:
- Added missing `license` field in pyproject.toml file
- Fixed editable mode install and some more code cleanup in setup.py
- Refreshed README.md
- Replaced f-string formatter in tests with `format` method in order to be py2-compatible
- Fixed typos
- PEP8 fixes
* GitHub Action: Install Python2.7 and run tests for re-tagged wheels on native arch runners only
* Python bindings:
- Use #x formatter to format hex values
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.
