|0.2.3||Jan 2, 2022|
|0.1.4||Jan 2, 2022|
|0.1.3||Sep 29, 2021|
|0.1.1||Jul 21, 2021|
|0.0.3||Mar 15, 2020|
#1 in #armv8
530 downloads per month
Used in 7 crates (3 directly)
yaxpeax-arm provides implementations of decoders for the armv7, v7/thumb, v7/thumb2, and aarch64/a64 instruction sets.
the entrypoint to begin decoding is either
default for both decoders is to decode in ARM mode.
default will try to decode as permissively as possible, even attempting to produce some kind of instruction for
UNPREDICTABLE patterns, where possible. for armv7 and below,
default_thumb produces a similarly permissive set of rules, but for decoding thumb/thumb2 instructions.
ARMv7 and thumb mode instructions decode to the same structure:
armv7::Instruction. this is not known to introduce ambiguities, and if you must discern thumb vs non-thumb origins,
armv7::Instruction::thumb will reflect the decoder state when decoding the instruction of interest. additionally,
armv7::Instruction::w reports if the instruction was a wide (32-bit) thum instruction.
for all ARMv7 instructions,
armv7::Instruction::s() reports if the instruction will update status flags. if
s is in error, that is a decoder bug, please report it.
- very fast
- pretty small?
yaxpeax-arm supports use in
no_std environments. to build
no_std environments, add
default-features = false to the crate's depdency line. this disables the
std feature, and removes the little integration with
yaxpeax-arm optionally provides.
yaxpeax-arm hasn't been exhaustively benchmarked, but loose tests suggest that it's at least as fast as other high-quality
arm disassemblers, like
bad64. more comprehensive benchmarks to come.
similarly to decode speed, the size of a compiled
yaxpeax-arm hasn't been closely profiled, but at minimum it's 20% the size of
armv8 code being entirely independent - using only one architecture should allow the other's code to be dead-code-eliminated.
yaxpeax-arm compiles in release mode in only a few seconds.
0.1 and 1.0 versions are considered significant indicators of feature-completeness and stability. the specific guidelines by which
yaxpeax-arm will be considered stable are listed below.
NEON(SIMD before SVE supported in ARMv8!)
min_lengthcan be contingent on the mode of
min_lengthis always 4, which is incorrect for
Thumbmodes. conversely, selecting "2" would be flagrantly wrong for
- address all in-tree TODO
- support per-version decode flags, so decoding an armv4, armv5, or armv7 instruction
- fully support
should_is_mustto control how pedantic decoding should be
- fully support reporting
- exhaustively test armv7 and armv8 instructions against other decoders
- existing thumb test suite is derived from enumerating thumb instructions, but is missing some
! user beware !
- armv7 NEON support is still nonexistent
Reproduced from infocenter.arm.com:
|r0-r15||r0-r15||These are the the registers!|
|a1-a4||r0-r3||Argument, result, or scratch registers|
|sb||r9||Static base register|
|ip||r12||Intra-procedure call register|
fp does not appear to be explicitly referenced in ARM documentation, and mapping to r11 looks to be OS (Windows/Linux?) convention.