| Age | Commit message (Collapse) | Author |
|
|
|
the motivating case is `xchg ah, al`, where both register writes
independently "don't match" the overall register diff of the low 16
bits. the diff-checking code was too narrow: we really have to collect
all allowed diffs on a register for an instruction and compare the
actual diff to that unification.
the implementation goes the other way though: compute the diff, and
remove parts of the diff that are unaccounted for. if any diff remains,
that is by definition unexpected and an error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
first, the vcpu is configured with 1G pages, which confound linux's
gva->gpa translation done as part of instruction emulation. this means
that we get bogus faults in perfectly valid virtual addresses that the
hardware can use, but linux cannot.
second, relying on mmio means every mmio-trapped instruction is actually
testing yaxpeax-x86 semantics against linux x86 emulation. while this is
interesting, it is not the goal of the tests. maybe some later day!
finally, write_matches_reg() had an inappropriate mask for what bits can
be written given a certain register size.
|
|
|
|
|
|
|
|
also shrink the GDT to 256 entries because i really won't use 8k of
them. this makes the GDT entries only 0x400 bytes but i still skip a
page from gdt_addr() to idt_addr().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this was missed in typical testing because either tests run with all
features, no features, or fmt. there wasn't a test entry for only std,
which was broken.
|
|
tweaks too
|
|
this is backed by the new IsaSettings trait. the existing InstDecoders
are unchanged, except that they implement this new trait.
also add new `DecodeEverything` structs with `IsaSettings` impls that
are unconditionally set to permit anything the decoder can be configured
to conditionally accept or reject.
in the process, add new `_3dnow` flag and stop accepting 3dnow
instructions in uarch-specific decoder settings that would not have
3dnow instructions.
update AMD microarchitectures and cross-ref chip directory
|
|
|
|
fix 32-bit 66-prefixed ff /2 call not having 16-bit operands
fix momentary regression in rendering `call` instructions to string
|
|
|
|
|
|
comes with deleting the body of impl Colorize for Operand, because we can reuse the normal operand formatting code
|
|
|
|
|
|
|
|
|
|
write_2 will never actually be used, but im adapting it into contextualize in a... better way
|
|
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...
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|