Update FAQ
This commit is contained in:
parent
720c61344f
commit
c1a391cb6b
26
docs/FAQ.md
26
docs/FAQ.md
|
@ -5,7 +5,7 @@ Typically, it’s due to
|
|||
- Instrumenting every instruction executed.
|
||||
- Instrumenting every memory access.
|
||||
|
||||
Optimize your program with less instrumentation.
|
||||
Optimize your program with less instrumentation, e.g. by using `UC_HOOK_BLOCK` instead of `UC_HOOK_CODE`
|
||||
|
||||
## Why do I get a wrong PC after emulation stops?
|
||||
|
||||
|
@ -26,6 +26,7 @@ On x86, all available instructions are: `in` `out` `syscall` `sysenter` `cpuid`.
|
|||
1. Some instructions are not enabled by default on some architectures. For example, you have to setup CSR on RISC-V or VFP on ARM before emulating floating-point instructions. Refer to the corresponding manual to check if you leave out possible switches in special registers.
|
||||
2. If you are on ARM, please check whether you are emulating a THUMB instruction. If so, please use `UC_MODE_THUMB` and make sure the starting address is odd.
|
||||
3. If either is not the case, it might be some newer instruction sets that qemu5 doesn’t support.
|
||||
4. Note some instruction sets are not implemented by QEMU.
|
||||
|
||||
If you are still using Unicorn1, please upgrade to Unicorn2 for better support.
|
||||
|
||||
|
@ -37,6 +38,29 @@ It is due to the fact that, if users return `true` without memory mapping set up
|
|||
|
||||
See the [sample](https://github.com/unicorn-engine/unicorn/blob/c05fbb7e63aed0b60fc2888e08beceb17bce8ac4/samples/sample_x86.c#L1379-L1393) for details.
|
||||
|
||||
## My MIPS emulation gets weird read/write error and CPU exceptions.
|
||||
|
||||
Note you might have an address that falls in MIPS `kseg` segments. In that case, MMU is bypassed and you have to make sure the corresponding physical memory is mapped. See [#217](https://github.com/unicorn-engine/unicorn/issues/217), [#1371](https://github.com/unicorn-engine/unicorn/issues/1371), [#1550](https://github.com/unicorn-engine/unicorn/issues/1371).
|
||||
|
||||
## KeyboardInterrupt is not raised during `uc.emu_start`
|
||||
|
||||
This is intended as python [signal module](https://docs.python.org/3.10/library/signal.html) states:
|
||||
|
||||
> A long-running calculation implemented purely in C (such as regular expression matching on a large body of text) may run uninterrupted for an arbitrary amount of time, regardless of any signals received. The Python signal handlers will be called when the calculation finishes.
|
||||
|
||||
A workaround is to start emulation in another thread.
|
||||
|
||||
## Editing an instruction doesn't take effect/Hooks added during emulation are not called.
|
||||
|
||||
Unicorn is a fork of QEMU and inherits most QEMU internal mechanisms, one of which is called TB chaining. In short, every block (in most cases, a `basic block`) is translated, executed and __cached__. Therefore, any operation on cached addresses won't immediately take effect without a call to `uc_ctl_remove_cache`. Check a more detailed discussion here: [#1561](https://github.com/unicorn-engine/unicorn/issues/1561)
|
||||
|
||||
Note, this doesn't mean you have to care about Self Modifying Code because the read/write happens within emulation (TB execution) and QEMU would handle such special cases. For technical details, refer to the [QEMU paper](https://www.usenix.org/legacy/event/usenix05/tech/freenix/full_papers/bellard/bellard.pdf).
|
||||
|
||||
TLDR: To ensure any modification to an address will take effect:
|
||||
|
||||
1. Call `uc_ctl_remove_cache` on the target address.
|
||||
2. Call `uc_reg_write` to write current PC to the PC register, if the modification happens during emulation. It restarts emulation (but doesn't quit `uc_emu_start`) on current address to re-translate the block.
|
||||
|
||||
## How to emulate interrupts (or ticks) with Unicorn?
|
||||
|
||||
As stated, Unicorn is a pure CPU emulator. For such emulation, you have two choices:
|
||||
|
|
Loading…
Reference in New Issue