| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 15c821a2d3fbf2fc0458090b6cc12f2ac093f075.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not a huge improvement, but something
|
|
these instructions ignored rex bits even for xmm reigsters, which is
incorrect (so says xed)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vex/rex prefix cleanup, finally profitable to inline read_0f*_opcode
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
set_embedded_instructions was unnecessarily appilied to many operand
codes; this was never a correctness issue, but meant many operand
decodings took a few more instruction than necessary to do nothing.
setting all registers to `rax` is unnecessary, only the first register's
defaulting to `rax` is effectual. this allows for not using a movabs to
load initial rax state.
adjust vex decoder inlining. this will be followed up by some cleanup
for vex operand codes.
|
|
slightly fewer (perfectly predicted anyway) branches this way
|
|
|
|
|
|
|
