| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if mem_size is ever out of bounds thats a severe bug on its own
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
it turns out that yaxpeax-arch's notion of colorization has been broken from the start for systems that do markup without inline sequences (e.g. windows/cmd.exe before vt100 support)
|
|
`name()` returning a `[u8; 2]` is nice when there is a specializing and
unrolling write implementation, whereas `&str` might not consistently
unroll into a simple 2-byte copy (rather than loop). it'll look a little
more reasonable soon, hopefully..
|
|
|
|
|
|
write_2 will never actually be used, but im adapting it into contextualize in a... better way
|
|
the reasoning for *why* `visit_operand` is better here lives as doc
comments on `visit_operand` itself: it avoids going from scattered
operand details to `enum Operand` only to deconstruct the enum again.
instead, branch arms can get codegen'd directly against `struct
Instruction` layout.
|
|
this reduces a `slice::contains` to a single bit test, and regroups
prefix printing to deduplicate checks of the `rep` prefix
seemingly this reduces instruction counts by about 1%, cycles by 0.3% or
so.
|
|
the match on opcode should have been dce, match on operands would only matter if there was a bug
|
|
|
|
|
|
testing against six opcodes to see if we should print rep or repnz is a
bit absurd. they are relatively rare instructions, so this is a long
sequence of never-taken tests. we can avoid the whole thing in the
common case by testing if there is any kind of rep prefix at all.
|
|
it is almost always the case that self.prefixes.segment == Segment::DS,
meaning testing for it first avoids checking
`self.operands[op].is_memory()` later. this overall avoids a few
instructions in the typical path, rather than checking `is_memory()`
first (which would always be true in the places this function is called
from)
|
|
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?
|
|
just report it having one operand...
|
|
also adjust changelog for a 1.2.1 version again, no new interfaces to go
with these bugfixes.
|
|
|
|
|
|
|
|
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.
|
|
registers `al`, `cl`, `dl`, and `bl` could have two different
representations - with `rex.w` and without. these two forms of `RegSpec`
would not compare equal, nor has the same, so for code relying on
`RegSpec` to faithfully represent a 1-1 mapping to x86 registers, these
synonyms would introduce bugs in register analysis.
for example, in `yaxpeax-core`, this would result in instructions
writing to `rex.w al` not being visible as definitions for a future
read of `!rex.w al`.
fix this in `x86_64` code, add new test cases about the confusion,
adjust register names to make this situation more clearly a bug, and
introduce two new fuzz targets that would have helped spot this error.
|
|
* 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
|
|
these functions had a copypaste error where the r12 and r13 versions
would create RegSpec for registers 8 and 9 instead of 12 and 13. use
correct register numbers in these macros.
|
|
|
|
|
|
|
|
|
