From 9687a5af1d712da41992cba8d241ddef8bdc50ec Mon Sep 17 00:00:00 2001 From: iximeow Date: Sat, 21 Aug 2021 13:13:26 -0700 Subject: clarify inaccurate 32/16-bit `call/jmp [mem]` mem_size --- src/protected_mode/mod.rs | 14 +++++++++++--- src/real_mode/mod.rs | 18 +++++++++++------- test/long_mode/operand.rs | 3 +++ test/protected_mode/operand.rs | 4 ++++ test/real_mode/operand.rs | 7 +++++-- 5 files changed, 34 insertions(+), 12 deletions(-) diff --git a/src/protected_mode/mod.rs b/src/protected_mode/mod.rs index 8381d68..79eb1b1 100644 --- a/src/protected_mode/mod.rs +++ b/src/protected_mode/mod.rs @@ -4223,6 +4223,15 @@ impl Instruction { /// the corresponding `MemoryAccessSize` may report that the size of accessed memory is /// indeterminate; this is the case for `xsave/xrestor`-style instructions whose operation size /// varies based on physical processor. + /// + /// ## NOTE + /// + /// the reported size is correct for displayed operand sizes (`word [ptr]` will have a + /// `MemoryAccessSize` indicating two bytes) but is _not_ sufficient to describe all accesses + /// of all instructions. the most notable exception is for operand-size-prefixed `call`, where + /// `66ff10` is the instruction `call word [eax]`, but will push a four-byte `eip`. this same + /// imprecision exists for `jmp word [mem]` as well. tools must account for these inconsistent + /// sizes internally. pub fn mem_size(&self) -> Option { if self.mem_size != 0 { Some(MemoryAccessSize { size: self.mem_size }) @@ -7516,9 +7525,8 @@ fn read_operands::Address, Option { if self.mem_size != 0 { Some(MemoryAccessSize { size: self.mem_size }) @@ -7516,13 +7525,8 @@ fn read_operands::Address,