IDA 9.4 comes with a brand-new Qualcomm Hexagon DSP module, an MCore family covering C-SKY V1, and deeper coverage of ARM, TriCore and RISC-V.
We've added a new processor module for Qualcomm Hexagon. If you reverse Snapdragon firmware (audio and compute DSPs, modems or newer NPU images), IDA now disassembles and analyzes it, with loaders for both ELF and Qualcomm's MBN container.
A couple of remarks about Hexagon:
.new operands.:endloop0 / :endloop1.The output is configurable. Through the processor options you can move braces onto their own lines, show slot labels or annotate .new producers.
For 9.4 we used the occasion to add C-SKY V1. It is derived from and largely compatible with Motorola/Freescale M-CORE, so the two share the decoder.
Supported by the module:
= symbol, with the pool entry and its cross-references resolved (e.g. lrw r7, =aBootseqNormal).The C-SKY V1 support covers the CK510, CK610, CK610E and CK620 cores, including their coprocessor and DSP/multiply instructions, in both little- and big-endian variants. The ELF loader detects C-SKY binaries and handles MCore/C-SKY relocations.
In IDA 9.3, you could decode the SVE/SME subset that turns up in Apple kernels. For 9.4, we implemented the whole thing: the full AArch64 SVE, SVE2, SME and SME2 instruction sets, including the scalable vector registers (Z), predicate registers (P), multi-vector and indexed SME2 operations, and MUL VL addressing.
ARM architecture detection selects an appropriate SVE/SME profile based on the binary’s reported architecture and attributes. As a heuristic, ARMv8.2 targets select SVE, ARMv9 targets select SVE2, and generic AArch64 targets enable SVE2+SME2. You can override it from the processor options if the detection is wrong, or disable the extensions entirely.
Two ABI improvements landed alongside it:
A few smaller disassembly fixes:
STM SP is recognized as a multi-slot stack-argument store.UDF decoding for AArch64.TBB-style switch recovery.TriCore is the core of Infineon's AURIX family, a dominant microcontroller in automotive ECUs. For 9.4, we gave the module a real type system and an explicit calling-convention model. IDA now knows how arguments and return values are laid out across the TriCore register banks, so function prototypes, argument types and cross-references come out far more accurate on AURIX firmware. This is the groundwork for a decompiler, but it makes everyday disassembly more useful today.
Usually TriCore passes the first integer/pointer arguments in the data and address register banks (D4–D7, A4–A7) and spills the rest to the stack. IDA now models this directly: it computes argument locations, the return location, and the varargs layout from a function's prototype, and it distributes operands across the D/A banks the way the ABI requires.
Two common ABIs are selectable from the processor options: the GCC/HighTec EABI and the TASKING ABI. These differ in how some arguments and return values are allocated. IDA will automatically apply heuristics to guess the ABI during analysis, but the user can always change it from "Options/Compiler.../ABI name".
Alongside the ABI work, we improved several analysis passes:
Built-in memory maps and peripheral-register definitions for the latest AURIX TC4x devices — TC45x, TC48x, TC49xN and TC4Dx. Selecting one of these devices lays out the on-chip memory map and names the special-function registers, so peripheral accesses in firmware read as CAN_17_MCMCAN_F0SA instead of a raw address.
RISC-V keeps spreading into security chips and microcontrollers, and the vendor custom-extension space has grown with it. For 9.4 we widened RISC-V coverage on both fronts.
Soteria (Xsoteria) is a custom RISC-V extension encountered in security-chip firmware.
Those opcodes overlap with other vendor extensions (the Andes XAndesPerf set uses the same encodings), so IDA cannot always tell which vendor a word belongs to from the bytes alone. Rather than guess silently, it decodes the configured extension and prints the alternative reading as a comment (alt Xsoteria / alt XAndesPerf), so an analyst working on the wrong assumption sees it immediately.
The non-trivial Soteria instructions lift to microcode and surface as intrinsics in the pseudocode, while constant-argument forms are folded locally:
Hazard3 is the RISC-V core in the RP2350 (Raspberry Pi Pico 2). IDA decodes its custom instructions, including the inter-hart synchronization primitives. RP2350 firmware decompiles cleanly, down to the SDK GPIO helpers.
The compressed-ISA support was extended with the Zcmp, Zcmt, Zclsd, Zcb and Zihintntl extensions, plus semihosting recognition. Compressed instructions now carry an explicit c. prefix in the listing (c.addi, c.sw, c.j), so it is obvious at a glance which instructions are 16-bit.
IDA now decodes the full RISC-V HINT space, including standard hints, pause, NTL, semihosting markers, and vendor-reserved encodings. Think of a hint as a "do-nothing" instruction that signals the CPU something (cache, pause) without changing state. Expect to see inline IDA annotations along such instructions.
For example:
All the new silicon above has to be debugged somewhere, and for embedded and DSP targets that usually means a remote GDB stub reached over JTAG or a gdbserver. For 9.4 we went through IDA's GDB remote serial protocol (RSP) client and made it more compliant and more compatible with third-party and embedded stubs, plus added a couple of conveniences aimed squarely at microcontroller work.
x/X memory transfers when the stub advertises them.qXfer:libraries-svr4:read, the full qXfer:libraries:read XML format, and qXfer:memory-map:read.Taken together, 9.4 reaches further into embedded and DSP silicon. This is just the groundwork for more in-depth analysis to come. Many of these improvements started as customer requests - thank you for your feedback! If there’s a processor, ISA extension or debugging workflow you’d like to see supported, tell us on the forum: https://community.hex-rays.com/.