1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
# 10 — related work: why not Frida, and what each tool is for
> **# TOOL IN DEVELOPMENT - NOT READY YET!** See 00 for status.
## 1. Frida
**Verdict for the firmware VM: not applicable.** Upstream Frida ships no
RISC-V target (checked against the 17.20 release assets: x86/x86_64,
arm/arm64, mips, macOS/Windows/QNX/Prospero — no `linux-riscv64`), and
frida-agent requires a hosted OS process. The GSP image is bare-metal RV64
with its own libos; there is nothing to inject into, and even a hypothetical
RISC-V port would need an OS layer the firmware does not have.
**Where the Frida *idea* lives in green-eye:** the scripting model. `Session`
offers `hook`/`watch`/`memory`/`events` with Python callbacks, which is the
part of Frida that matters for this workflow. The difference is transport:
RSP to QEMU instead of an injected agent.
**Where Frida is applicable in the project:** host- or guest-userland x86_64
work (e.g. the CUDA userspace layer) if a dynamic tracer is ever wanted there.
That is outside this tool's scope; the existing ptrace tracer covers the
guest today.
## 2. GDB / gdbstub
QEMU's gdbstub is the transport both tools share. GDB itself is still useful
for *debugging green-eye* (stub behaviour, protocol traces), and `gdb
-multiarch` can inspect the same target interactively. It is not the
instrumentation layer here because:
* every operation becomes a subprocess/parse problem instead of an API call;
* recording, symbol annotation, structure decoding and session diffing would
have to be rebuilt around GDB/MI anyway;
* the project already uses GDB Python scripts for the CUDA corpus; green-eye
is the equivalent for firmware, with a stronger data model.
## 3. QEMU TCG plugins
The correct complement, not a competitor: plugins execute inside QEMU and can
observe **every** instruction and memory access, which gdbstub breakpoints
cannot. green-eye's `qemu/greeneye_trace.c` emits a JSONL access trace for
exactly this; integrating it into the session format is R4 on the roadmap.
Rule of thumb: use green-eye hooks for semantics ("handler X ran with these
args") and TCG plugins for coverage/heatmaps ("every write to this window").
## 4. Unicorn / emulator libraries
Unicorn (and similar CPU emulators) can execute RV64 code faster to set up
than QEMU and embed cleanly in Python, but they model no board at all and
have weaker debug infrastructure. They are candidates for the **custom
simulator** (R2) once the required device semantics are known — the same
reason the roadmap defers that work.
## 5. `rr` / record-replay
`rr` does not support RISC-V guests and records at the host-process level.
QEMU's own record/replay (`-icount`) can provide deterministic reruns later;
green-eye's session recording occupies a different niche (semantic events,
not full replay) and can coexist.
## 6. Comparison table
| Tool | Layer | RISC-V firmware | green-eye relationship |
|---|---|---|---|
| Frida | userland process injection | no | conceptual model only |
| GDB + gdbstub | execution control | yes (transport) | debugging green-eye; same stub |
| QEMU TCG plugin | full instruction/memory trace | yes | complement (R4) |
| green-eye | semantic instrumentation + recording + analysis | yes | this tool |
| Unicorn/rv8/etc. | CPU emulation library | yes | R2 candidate |
| Ghidra | static decompilation | yes | symbol/hit bridge (05) |
## 7. Reading list
* `docs/01-DESIGN.md` — where each layer sits.
* `docs/05-GHIDRA-BRIDGE.md` — the static/dynamic join.
* `docs/08-ROADMAP.md` — R1 device model, R2 custom simulator, R3 MCP.
|
