| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the T1 TBH arm set Opcode::TBB instead of Opcode::TBH, and built the
index operand with bit 4 set in the RegShift raw value. bit 4 is the
RegReg selector in RegShift::into_shift, so the mandatory 'lsl #1' index
scaling decoded as a register shift 'lsl r0' instead. clear bit 4 so it
reads back as the RegImm 'lsl #1' the encoding specifies.
verified against binutils objdump: df e8 13 f0 is tbh [pc, r3, lsl #1].
|
|
- register-controlled shifts (lsl/lsr/asr/ror by register) all decoded as
lsl: the shift type was read from hw1[6:5] (always 0 for this form)
instead of hw0[6:5]
- 32-bit uxt*/sxt* extends read the ror amount from the wrong field
(hw1[2:1] scaled by 4 instead of hw1[5:4] scaled by 8), so a no-rotation
extend came back as ror #4; rotation of 0 is now omitted
- sxtab was decoded as sxtah (wrong opcode table entry)
all cases verified against binutils objdump
|
|
|
|
- 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
|
|
|
|
|
|
Previously, immediate-shifted-register and register-shifted-register
data-processing instructions were decoded using separate decoding paths,
which caused extra complexity. These two forms differ only in the
interpretation of their shifting constructs, which is already handled
through the `RegShift` type.
This change also fixes instructions like `cmp r0, r1, lsl r2` from being
decoded with an extra operand.
|
|
|
|
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>
|
|
|
|
they share exactly the same encoding, except the high bits for condition
the bool indicates if it's A2 encondings which is unconditional
|
|
|
|
|
|
|
|
|
|
A format precision specifier consisting of a dot and no number actually does nothing and has no specified meaning. Currently this is silently ignored, but it may turn into a warning or error.
See rust-lang/rust#131159 and rust-lang/rust#136638
|
|
|
|
but exhaustiveness checking is very valuable here, so allow it to be
disabled. caveats apply. read the docs in Cargo.toml.
|
|
|
|
|
|
|
|
this makes a decode+format benchmark drop from 75s to 14s...
(decode is 5s)
|
|
|
|
both from_u8 and the build function here compiled to truly trivial code:
four instructions (mov rdi, rax; cmp 0xlim, rax; jae panic; ret) in the
hot path, and constrained register choice on the caller side. inlining
these makes for a *smaller* armv7 decoder, on the order of 5kb down from
5.5kb. in the process it also gets about 45% faster (400mb/s to 560mb/s)
inlining decode_into, then, really just helps the standalone decoder
benchmark case. this moves decode throughput from 560mb/s to 724mb/s.
|
|
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
|
|
|
|
|
|
|
