Re: [Qemu-devel] Binary Translation hooking - reading registers

[Peter Maydell]

On 13 February 2011 17:14, address@hidden
<address@hidden> wrote:
> To be more specific on my env update problem, here an example:
>
> push ebp
> mv esp,ebp
> /* do something */
> call 0xfoo
> test eax,eax
> /* do something */
> ret
>
> The first line is the start of a block. What I did was adding a
> gen_helper_instrument_call in the 'call' opcode cases in disas_insn()
> which will call my analysis code to examine from where the call is
> launched, where it will go and what is the address we will return to
> after (in this case regarding to call 0xfoo).
> Because in this case, usage of tcg_const_i32(pc_start) and providing
> CPU_T[0] as parameters to my generated helper, I can provide all three
> values. But what I would _assume_ is that after
> gen_helper_instrument_call is executed, env->eip would point towards
> 'call 0xfoo', but it points to 'push ebp'.

Ah, you should have said you were talking about EIP; you've
hit an optimisation case. If we updated env->eip after every
instruction then this would slow things down. Instead, since
we know what the value is statically at translate time, we can
just use that calculated value mostly. We only update env->eip:
 * at the end of the TB
 * when we translate jump commands (usually ends the TB)
 * when we translate something that will raise an exception
   or some other thing we know will need an accurate env->eip
Unexpected interrupts (typically faults on load/store) are
handled by constructing a mapping from host PC to guest
PC and then looking up the host fault address in it and
resetting env->eip (in gen_pc_load()).

Which registers are dealt with like this varies from target to
target; on target-arm we do this for both r15 (pc) and the
IT state bits in the CPSR, for instance.

The other case to watch out for is where the value of some
register is kept in env, but as a broken out set of components
which are only reassembled into the actual register value
when the target needs to read it; see for example the comment
in target-i386/cpu.h about env->eflags.

If the registers you care about aren't in either of these
categories you should be able to trust them in a helper fn.
This typically includes most of the general purpose registers.

-- PMM