|
From: securitypotato <sec...@gm...> - 2013-06-23 07:09:27
|
Hi ! Is anyone know what is the meaning of x86_calculate_condition expression |
|
From: Stephen M. <sm...@al...> - 2013-06-24 17:47:00
|
>>>>> "SP" == securitypotato <sec...@gm...> writes:
SP> Hi !
SP> Is anyone know what is the meaning of x86_calculate_condition
SP> expression
In x86 hardware, every time an (e.g.) "add" instruction occurs, the
processor computes flags that tell whether the result was zero,
whether it was negative, whether it overflowed, and a few
others. Sometimes these flags are later used in a conditional jump
like "jne", though most of the time most of the flags are just
ignored. In hardware this a cheap capability to provide because the
flag computations can happen in parallel. But in software simulation
if you did a straightforward translation that recomputed all the flags
after every instruction, it would be expensive.
Instead, Valgrind uses a lazy translation of the EFLAGS side effects
of x86 instructions (and similar condition-code flags on other
architectures). When an add instruction happens, Valgrind's
translation doesn't compute the flags, it just stores enough
information (basically the identity of the operation and its operands)
so that it can recompute the flag value if it later turns out to be
needed. An academic reference for this idea is section 6.3 of the tech
report on Shade:
@techreport{CK:93,
author={Robert F. Cmelik and David Keppel},
title={Shade: A Fast Instruction-Set Simulator for Execution
Profiling},
number={SMLI 93-12, UWCSE 93-06-06},
year={1993}
}
http://www.cs.washington.edu/research/compiler/papers.d/shade.html
There's also a brief mention in section 3.7 of the PLDI 2007 Valgrind
paper.
In Valgrind's translation, x86g_calculate_condition is the clean
helper routine that does the computation of a flag-based condition
value for an x86 guest. A typical call will look like:
x86g_calculate_condition(0x4:I32,GET:I32(32),GET:I32(36)
GET:I32(40),GET:I32(44))
The exact encoding of the arguments is explained in a long comment
that starts "%EFLAGS thunk descriptors" in VEX/priv/guest_x86_defs.h.
At the hardware level, there are two steps: the operation sets some of
the six flags in EFLAGS, and then later the branch condition is
computed as some combination of those. But x86g_calculate_condition
does both steps in one helper. The first argument is the kind of
condition to compute; in this example 4 means X86CondZ, for instance
from a jz (jump if zero) instruction. The four remaining arguments are
the saved information about the flag-setting operation, stored in the
guest state as CC_OP, CC_DEP1, CC_DEP2, and CC_NDEP.
Hope this helps,
-- Stephen
|