Files

T

marfrit 282d23fff7 benchmark/05_prep_freq_change: second poll-site function, reference-C only

FUN_0000d10c @ 0xd10c (49 insts) contains poll site 11.
Semantically decoded as a PHY-side prologue for frequency-change
handshake: saves current state of one PHY CTL + four secondary-table
entries, waits for PHY firmware to reach state 1 (idle).

Matching-decomp iteration deferred vs the clean first lift (d328) —
d10c's two-base-pointer csel pattern plus parity-dependent offset
chain gives GCC too much register-allocation freedom. Getting to
>=90% byte-match would be an afternoon of iteration; time better
spent expanding pre-UART coverage breadth.

Poll-site coverage so far:
  d328: sites 12, 13, 14, 15 (C candidate at 89.7% size match)
  d10c: site 11 (reference C only, no matching iteration)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-04-15 08:14:00 +02:00

01_memset

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

02_memcpy32

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

03_magic_memset

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

04_train_phy_block

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

05_prep_freq_change

benchmark/05_prep_freq_change: second poll-site function, reference-C only

2026-04-15 08:14:00 +02:00

ai_ghidra

benchmark: AI-Ghidra landscape + case-4 harness (synthetic PHY)

2026-04-15 08:03:43 +02:00

gdb_debug

benchmark: AI-Ghidra landscape + case-4 harness (synthetic PHY)

2026-04-15 08:03:43 +02:00

extract.py

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

README.md

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

RESULTS.md

benchmark/: three-way RE-tool comparison + first real C-lift

2026-04-15 07:26:23 +02:00

README.md

RE-tool benchmark — three functions from the RK3588 DDR blob

Three small, self-contained functions extracted from rk3588_ddr_lp4_1848MHz_lp5_2112MHz_v1.19.bin, each with canonical ground-truth semantics so you can judge decompiler output against a known answer.

dir	blob offset	size	ground truth
`01_memset/`	`0x0aac`	28 B / 7 insts	`memset(void*, u8, size_t)` byte-wise
`02_memcpy32/`	`0x1200`	36 B / 9 insts	`memcpy32(u32, const u32, size_t)` word-aligned
`03_magic_memset/`	`0x0da4`	40 B / 9 insts	`if ((u32)0x1fe004 == 0x54410001) memset(0x1fe000, 0, 0x32c);`

Each subdir contains:

func.bin — raw little-endian AArch64 machine code
func.s — objdump'd GNU asm, same absolute addresses as the blob
reference.c — ground-truth C (our belief)
ghidra.md — load-in-Ghidra recipe + expected output
decompme.md — decomp.me scratch recipe (matching-decomp)
retdec.md — retdec command line
retdec.c — retdec's actual output (captured 2026-04-15)

Summary of findings: see RESULTS.md. Short version:

Ghidra got all three right with minor type-label cleanup needed.
retdec failed on #1 and #2 (can't infer register-passed arguments on raw binary), did well on #3 (the one with absolute-address refs).
decomp.me is a matching-decomp comparator, not a decompiler — judged on a different axis.

Load address matters

All three functions are extracted as raw bytes starting at offset 0 in their func.bin. When loading into Ghidra / retdec, set the base address to the function's original blob offset (first column above), otherwise branch targets and absolute-address refs in function #3 will be off.