| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the comment was even correct! but the actual check was not.
|
|
|
|
|
|
extended register forms of ld*/st* instructions do not shift by 0 or 1,
they are an instruction/operand-size-dependent shift amount.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
only in a64 decoding really; there wasn't an "Incomplete" error at the time, but now there is.
|
|
|
|
|
|
|
|
fix interface changes around YaxColors as well
|
|
instead of trying to shoehorn in `adr reg, label` syntax like the manual
requests, it's much easier to just describe these as `{add, sub} reg,
pc, offset` and potentially rewrite `pc, offset` as an `adr reg, label`
if a higher-level tool has that kind of information available.
|
|
|
|
add in some simd tests for future neon decoding. these tests are drawn
from capstone and may need some subsequent cleanup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mostly confusion of pre/post-increment, operand widths, immediate
widths, things of that nature
|
|
16-bit instructions only, for now
|
|
|
|
|
|
|
|
|
