| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
comes with deleting the body of impl Colorize for Operand, because we can reuse the normal operand formatting code
|
|
|
|
be ... stern
|
|
for mem size labels: add one new "BUG" entry at the start of the array
so `mem_size` does not need to be adjusted before being used to look
up a string from the `MEM_SIZE_STRINGS` array. it's hard to measure
the direct benefit of this, but it shrinks codegen size by a bit and
simplfies a bit of assembly....
for segment reporting changes: stos/scas/lods do not actually need
special segment override logic. instead, set their use of `es` when
decoded, if appropriate. this is potentially ambiguous; in non-64bit
modes the sequence `26aa` would decode as `stos` with explicit `es`
prefix. this is now identical to simply decoding `aa`, which now also
reports that there is an explicit `es` prefix even though there is no
prefix on tne instruction.
on the other hand, the prefix-reported segment now more accurately
describes the memory selector through which memory accesses will
happen. seems ok?
|
|
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.
|
|
|
|
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.
|
|
Closes https://github.com/iximeow/yaxpeax-x86/issues/16
|
|
these instructions had memory sizes reported for the operand, if it was
a memory operand, but for versions with non-memory operands the decoded
`Instruction` would imply that non memory access would happen at all.
now, decoded instructions in these cases will report a more useful
memory size.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
it depended on crates that dragged in std, oops
|
|
really need to adjust OperandCode, almost out of one-off options...
|
|
this adds in some missing sse2 instructions in the alternate secondary
opcode map. because these were missing, instructions were incorrectly
decoded from the 0f opcode map, yielding mmx-operand versions of
themselves (usually)
there are undoubtedly more missing sse2 instructions from the 660f map.
|
|
this makes yaxpeax-x86 no_std. no externally-visible changes!
|
|
|
|
fix several instances of incorrect instruction lengths
* immediates for `mov reg, imm` and some other instructions were double-counted
* lengths for vex prefixes were wrong all over the place
|
|
|
|
|
|
this assists many misdecodes from being totally wrong to only slightly
wrong and more clear about it (rrr-selected opcodes or W-bit-selected
opcodes were accidentally decoded as the first variant of their opcode)
also fixes sillier warnings all over the place, and probably a few
incorrectly counted lengths
|
|
|
|
for hashmaps with heavy traffic keyed on RegSpec, this can be a significant time savings
|
|
|
|
|
|
this includes respecting ModRM_XXXX-style operand codes from alternate
0f opcode maps. this MAY introduce bugs where an opcode 0fXX is valid
by the 0f map, invalid by the 660f map, and we see a sequence like
660fXXYY. if YY results in 0fXX being invalid by 660f, we may have to
fall back to reading opcode XX as an 0f opcode, where YY needs to be
re-read with the correct operand code.
hopefully this doesn't actually happen...
|
|
|
|
|
|
add enclv instruction
add sse3, ssse3, sse4.1, and sse4.2 feature flags, plus a host of
missing opcodes
|
|
|
|
fence instructions
|
|
|
|
|
|
|
|
|
|
|
|
this makes all current non-vex/evex tests pass!!!
|
|
|
|
|
|
|
|
|
|
|
