| Age | Commit message (Collapse) | Author |
|---|
|
- 32-bit store encodings with the imm12 bit (bit 23) set were decoded as
the register-offset form when imm12 < 64, or as strbt/strht/strt when
imm12 was 0xExx. bit 23 set always means the imm12 form.
- movw/movt packed imm4 at bit 16 instead of bit 12, producing 20-bit
immediates (e.g. 0xf0005 instead of 0xf005)
- mvn (immediate) was decoded as mov, dropping the bitwise not
- ror (immediate) was decoded as asr
all cases verified against binutils objdump
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in fact the decoder should _never_ panic. included here are tests that
cover the entire 32-bit instruction space and ensure that decoding and
display do not panic. these tests run uncomfortably slowly (1168s to
decode the 4b "instruction" sequences on my desktop), but verify that
panics are no longer an issue.
|
|
|
|
|
|
add some keywords to the crate. this is a first for yaxpeax
|
|
|
