| Age | Commit message (Collapse) | Author |
|---|
|
This also incidentally fixes an issue where MOV/MVN instructions with a
shifted operand could be decoded as if they had 3 operands.
|
|
There's a pattern of load/store instructions that look something like
* `ldr<variant> <target registers>,
[<base register>, +/- <offset register>]`
* `str<variant> <target registers>,
[<base register>, +/- <offset register>]`
These instructions share a common encoding format, which includes the
presence of 4 reserved bits starting at bit 8 in the instruction word.
These bits should always be zero, according to
`DDI0406C_d_armv7ar_arm.pdf`. However, while this crate did attempt to
validate these bits sometimes, the validation was inverted. Instead of
checking that the bits were zero, the validation would raise an error if
all of the bits were zero! Additionally, some instructions were missing
the check and some instructions that did not use the aforementioned
encoding scheme incorrectly had the check applied to them.
This commit fixes all of the issues I've found along these lines so far.
|
|
|
|
|
|
|
|
initially was "implement MCR/MRC decoding", but expanded to include the
whole coprocessor space for completeness, and then SVC is right there
too.
Neon instructions in this space are still rejected, as neon support is
not really there yet.
Co-authored-by: iximeow <me@iximeow.net>
|
|
|
|
|
|
this makes a decode+format benchmark drop from 75s to 14s...
(decode is 5s)
|
|
capstone-rs currently binds an old capstone (4.0), where capstone 5.0 is
where much of the armv8.2+ implementation was ported over from LLVM. so,
differential testing is now pointed to a capstone-rs fork pending the
merge of https://github.com/capstone-rust/capstone-rs/pull/172
|
|
|
|
|
|
they run in minute or so now
and the thumb mode panics....???
|
|
|
|
|
|
circumstance.
|
|
|
|
|
|
* cN instead of crN for control registers
* # for immediates in sys/sysl instructions
* write out ARM system register names in the way the ARM reference manual says
|
|
|
|
|
|
.... and add tests that exercise movi with an immediate other than 0
|
|
also unignore tests that would have caught this
fix test expectation that predated using pc-relative syntax
and fix a test that expected an instruction to be disassembled as "invalid" successfully, rather than returning an error
|
|
"improve" rather than "fix" as `pstate.0x3` is hardly as useful as
`msr uao, #3`. but the "pstate field" that had been decoded before was
totally incorrect.
|
|
|
|
|
|
|
|
|
|
Correct the shift used to select condition bits and correctly compute the
branch offset.
|
|
Sign extension shift had an off-by-one error so the sign bit was not being
properly extended.
|
|
T4 encodings of unconditional branches were not being interpreted correctly
(#6), and 32-bit bl/blx instructions were similarly incorrect. Correct the bits
selected for op1 and op2 and handle the slightly-unusual i1/i2 sign bit xor for
these instructions.
|
|
|
|
|
