| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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?
|
|
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.
|
|
|
|
|
|
|
|
these coincidentally have the general-purpose banks (rB excepted) matching their size in bytes
|
|
|
|
Closes https://github.com/iximeow/yaxpeax-x86/issues/16
|
|
|
|
|
|
This makes generated docs refer to a type and show said type in the list of all structs rather than rustdoc showing gray text in return types.
quote doc references
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the evex route would allow "valid" instructions that have the opcode
`invalid`. this is.. not correct.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
instructions
|
|
|
|
|
|
|
|
does intel know no bounds
|
|
|
|
|
|
|
|
decoder flag to come
|
|
this is... a more significant rewrite than i expected yaxpeax-x86 to
ever need. it turns out that capstone is extremely permissive about
duplicative 66/f2/f3 prefixes to the point that the implemented prefex
handling was unsalvageable.
while this replaces the *0f* opcode tables, i haven't profiled these
changes. it's possible this is a net improvement for single-byte
opcodes, it could be a net loss. code size may be severely impacted.
there is still work to do.
but this in total gets very close to iced/xed/zydis parity, far more
than before.
also adds several small extensions, gfni, 3dnow, enqcmd, invpcid, some
of cet, and a few missing avx instructions.
|
|
|
|
|
|
initial work to optionally discard any instruction printing support
when using `-Z build-std` to fully remove .eh_frame, a stripped
long_mode_no_fmt .so is 61kb!
|
|
* `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
|
|
|
|
|
|
rep_any will get speculated `false` quite quickly, whereas checking if
the opcode is a string instruction will be costly no matter what. in the
rare case rep_any is true, i don't care how costly displaying the
instruction is - string instructions are relatively rare, and rep movs
is typically not more than one instance when it shows up.
|
|
the arms of the match in regspec_label referenced tables that were not
const. consequently, they would be rebuilt when reached, every time the
match is incanted. this holds through even when regspec_label is
inlined.
each arm could be a const array for a small and easy change, but to
avoid the indirect dispatch on spec.bank i've reorganized register names
into a single const array and selected values for `RegisterBank` such
that indices into that array can be formed.
for my next trick, i may make `REG_NAMES` a `*const u8`, with indices
picking offsets into the table - 8-byte offsets might do? this should
compact down size a little more by removing a pointer and size qword
for each string.
|
|
|
