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

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.

1 files changed, 12 insertions, 3 deletions

diff --git a/idatui/formats.py b/idatui/formats.py
index b2f784d..f09bb99 100644
--- a/idatui/formats.py
+++ b/idatui/formats.py
@@ -92,9 +92,18 @@ def needs_load_options(path: str) -> bool:
 #: reach for first — arm64, aarch64, mips, m68k — are all invalid. Re-run the
 #: script before adding to this list.
 PROCESSORS: tuple[tuple[str, str], ...] = (
-    # 'arm' covers AArch64 too; arm64/aarch64 are NOT valid -p names, so they
-    # live in the label where the filter can still find them.
-    ("arm", "ARM / AArch64 / arm64 — little-endian"),
+    # Bare 'arm' gives a 64-BIT database in IDA 9 (AArch64). That matters far
+    # more than it looks: Hex-Rays refuses a 32-bit function in a 64-bit database
+    # ("only 64-bit functions can be decompiled in the current database"), and
+    # Thumb doesn't exist in AArch64 at all — so a 32-bit ARM image loaded as
+    # plain 'arm' disassembles wrongly and can never be decompiled. The database
+    # bitness is fixed at load; it cannot be corrected afterwards (setting it
+    # post-hoc makes the decompiler INTERR). Pick the right one here.
+    ("arm", "ARM64 / AArch64 / arm64 — 64-bit, little-endian"),
+    ("arm:ARMv7-A", "ARM 32-bit (ARMv7-A) — Thumb capable, most firmware"),
+    ("arm:ARMv7-M", "ARM 32-bit (ARMv7-M) — Cortex-M, Thumb only"),
+    ("arm:ARMv6-M", "ARM 32-bit (ARMv6-M) — Cortex-M0/M0+"),
+    ("arm:ARMv5TE", "ARM 32-bit (ARMv5TE) — older SoCs"),
     ("armb", "ARM — big-endian"),
     ("metapc", "x86 / x86-64"),
     ("mipsl", "MIPS — little-endian"),