Age | Commit message (Collapse) | Author |
|
|
|
new `does_not_decode_invalid_registers` fuzzer found other bugs! the
384-bit accesses for 128b keylocker instructions are an
otherwise-unknown size and had a memory size of `BUG`. they are not
bugs. give the memory size a real name.
|
|
* the first four 1-byte registers, `al`, `cl`, `dl`, `bl`, can be
constructed in two ways that produce "identical" `RegSpec` that are..
not.
e.g. `RegSpec::al() != Regspec::rb(0)` even though
`RegSpec::al().name() == RegSpec::rb(0).name()`.
this corrects the `rb` constructor at least, but instructions like
`4830c0` and `30c0` still produce incompatible versions of `al`.
* also fix register numbering used explicit qword-sized RegSpec
constructors, r12 and r13 used to produce r8 and r9
|
|
|
|
|
|
|
|
this request/suggestion comes from
[github](https://github.com/iximeow/yaxpeax-x86/issues/29)! thank you!
|
|
|
|
this includes a `Makefile` that exercises the various crate configs.
most annoyingly, several doc comments needed to grow
`#[cfg(feature="fmt")]` blocks so docs continue to build with that
feature enabled or disabled.
carved out a way to run exhaustive tests; they should be written as
`#[ignore]`, and then the makefile will run even ignored tests on the
expectation that this will run the exhaustive (but slower) suite.
exhaustive tests are not yet written. they'll probably involve spanning
4 byte sequences from 0 to 2^32-1.
|
|
not only did the instruction have wrong data, but if displayed, the
formatter would panic.
|
|
in the process, fix 64-bit rex-byte limit, 32/16-bit mode mask reg limit
|
|
|
|
so multiplying to expand EVEX compressed offsets can overflow, and that
needs to be okay.
|
|
|
|
|
|
while x86 branches of immediates are all relative to PC, other
architectures may have absolute branches to immediate addresses, leaving
this syntax ambiguous and potentially confusing. yaxpeax prefers to
write relative offsets `$+...` as a rule, so uphold that here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
also remove redundant assignments of operand_count and some OperandSpec,
bulk-assign all registers and operands on entry to `read_instr`. this
all, taken together, shaves off about 7 cycles per decode.
|
|
|
|
also some long-mode cleanup in corresponding areas
|
|
|
|
|
|
|
|
|
|
* `mwaitx`, `monitorx`, `rdpru`, and `clzero` are now supported
* swapgs is no longer decoded in protected mode
* rdpkru and wrpkru are no longer decoded if mod bits != 11
|
|
base 0b101
for memory operands with a base, index, and displacement either
the wrong base would be selected (register number ignored, so only
`*ax` or `r8*` would be reported), or yaxpeax-x86 would report a
base register is present when it is not (`RegIndexBaseScaleDisp`
when the operand is actually `RegScaleDisp`)
thank you to Evan Johnson for catching and reporting this bug!
also bump crate version to 0.1.4 as this will be immediately tagged and
released.
|
|
|
|
`OperandCode` (obviously) wildly varies depending on how i feel on a
given week, so it's now hidden to avoid people depending on numerical
values of its discriminants.
`RegisterBank` got a similar treatment with a new `RegisterClass` struct
that's suitable for public use.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add tests for modrm/sib decoding, xsave extensions
|
|
additionally: cmpcxchg{8,16}b, rdrand, rdseed, rdpid, {rd,wr}{fs,gs}base
|
|
also add builders to get decoders appropriate for specific
microarchitectures from intel and amd
* low-power architectures are not yet present
|
|
this is largely wrong for memory operands, which require more invasive changes
|
|
|
|
|
|
|