arm: offer 32-bit ARM at load, and fix `p` on carved code

2026-07-26T13:04:51Z

Reported as "after c a few times and p at the entry point, Tab just flashes and nothing decompiles". Three separate things, found by following it down: **1. `p` failed on hand-carved code.** ida_funcs.add_func(ea) asks IDA to find the function's end and on carved code it often can't — a run ending in a tail call, or whose last instruction isn't recognised as a return, fails with no reason given. add_func(ea, end) with an explicit end succeeds. define_func_run tries IDA's way first, then falls back to the end of the contiguous instruction run, and says which it used. **2. The database was 64-bit, so Hex-Rays refused it regardless.** Bare `-parm` gives an AArch64 database. Ask Hex-Rays for the failure object rather than reading None as "dunno" and it says exactly what's wrong: "only 64-bit functions can be decompiled in the current database". So the disassembly looked right and F5 could never work. That is decided at LOAD and cannot be corrected — inf_set_app_bitness(32) afterwards makes the decompiler INTERR 50735. The fix is at the load dialog: arm:ARMv7-A (most firmware), arm:ARMv7-M / arm:ARMv6-M (Cortex-M, Thumb only) and arm:ARMv5TE now sit alongside 64-bit `arm`, labelled with their bitness. With arm:ARMv7-A, experiments/fibonacci.bin decompiles: void __fastcall __noreturn sub_0(int a1) { int v2; v2 = sub_E3C(a1, 0); ... } — and IDA's own auto-analysis finds 54 Thumb functions on load, versus none as plain `arm`. **3. `t` was silently building an undecompilable state.** It forced the SEGMENT to 32-bit in a 64-bit database, which produces correct-looking disassembly that F5 will never touch. It now says so and names the fix (Ctrl+L, arm:ARMv7-A) rather than leaving you to discover it. tools/verify_procs.py now reports each processor's resulting bitness, since that is the reason the variants exist — and it compares against the base module name, because a variant reports "ARM". tests: test_thumb_ui.py +5 (13 total) — a 64-bit database warns and names the fix, a 32-bit one finds functions by itself, Tab decompiles a Thumb function and the result reads like C. test_formats.py +2 (34) pinning that a 32-bit variant is offered and the ARM labels state their bitness. 209/0 scenarios, 26/0 blob, 30/0 project UI.

formats: verify every offered processor name against a real IDA

2026-07-25T22:04:38Z

The curated list was written from the procs/ directory listing. Two of the twenty names were wrong, and wrong here is not a soft failure: IDA REFUSES to open the database (rc=4) with nothing useful said. The load dialog would have handed people a dead end from inside the UI that exists to rescue them — the same silent-failure class the dialog was built to kill. h8 -> h8300 (h8.so is the module FILENAME, not a processor name) sparc -> sparcb / sparcl (and SPARC has endianness variants, like MIPS/PPC) Also probed the aliases people reach for first: arm64, aarch64, mips, m68k are all invalid. 'arm' covers AArch64 (verified: an AArch64 blob analyses to 35 functions under -parm), so those names now live in the human labels, where the filter still finds them — typing "arm64" finds ARM, "m68k" finds 68k, "mips" finds both endiannesses. tools/verify_procs.py does the check: open a scratch blob with -p, read back inf_get_procname(), compare. Fresh temp dir per name, because once a database exists IDA ignores the load switches and every name after the first would "pass". 21/21 verified. tests: +11 formats, including the verified-set guard (adding a processor without re-running the script fails on purpose) and checks that the rejected aliases are NOT offered but ARE still findable by typing them. 32/0 formats, 199/0 scenarios.

ida-tui.git/tools/verify_procs.py, branch main

arm: offer 32-bit ARM at load, and fix `p` on carved code

formats: verify every offered processor name against a real IDA