qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Static instrumentation (aka guest code tracing)


From: Lluís
Subject: Re: [Qemu-devel] [RFC] Static instrumentation (aka guest code tracing)
Date: Mon, 29 Nov 2010 16:04:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Paul Brook writes:

>> > Likewise requiring separate tracing hooks be added to the existing
>> > decoders is extremely unlikely to be a feasible long-term
>> > solution.
>> 
>> You mean having to modify each "translate.c"? The worst event to handle
>> is instruction fetch on x86.

> Instruction fetches are trivial, you just intercept calls to ld*_code.

For instruction fetch I mean:

* instruction address and length
* instruction opcode "type" (I'd like to have some kind of a rough
  generic opcode type: ALU, branch, etc.)
* set of used/defined registers

For the loads, ld*_code is not accurate, as the code might call it
multiple times, even on positions after the actual instruction, or
repeat calls for the saame position. I'ts much easier (I think) to do
the kind of trivial math I do on x86 with "s->pc".


>> > I'd also posit that instrumenting changes in sate is of very limited use
>> > if you don't know what the new value is.
>> 
>> I don't understand what you mean here.

> Your proposed FETCH macro instrumented which registers are modified by an 
> insn, but did not the actual values about to be written to those registers.

Right. Register values are not part of what I was looking for. Still,
having an accurate set of used/defined registers, you could be given the
option of gathering their values at "commit" time by, e.g., adding a new
tracing event after generating code for an instruction, with a CPUState
argument.

The combinations of data you might want to gather from guest code are
nearly infinite, and that's why I wanted to provide the minimum set of
information that, when you enable instrumentation of tracing events,
will let you gather all the rest (like values).


>> > You almost certainly want to do this using the equivalent of a memory
>> > watchpoint on the CPUState structure.
>> 
>> Sorry, do what?

> All guest register values are held in the CPUState structure. So to 
> instrument 
> accesses to guest state you just need to intercept TCG accesses to this 
> structure, either via explicit ld/st ops, or via a global_mem. To a first 
> approximation you can probably get away with just the latter.

I think I understand what you mean, and it would certainly simplify the
implementation, but it depends on being able to efficiently identify
from all memory accesses, which are directed to the interesting CPUState
fields, which is easy to get when using functions like
"tcg_gen_ld/st_i64", but will get almost impòpssible when the code
generator starts using multiple tcg operations to calculate the address
of a single access to a CPUState field.

But indeed this would be much more easily to maintain for the common
case, although probably slower:

- you have to register all the possible TCGv_ptr that can point to a
  CPUState (if you use something else, it will no longer work, although
  I don't know if there is any such case anywhere)
- register the "interesting" offsets (which can be multiple and
  non-consecutive: general-purpose registers, control registers in x86,
  mtrr, etc.)
- "decode" from those offsets which specific field is being accessed

This is supposing that CPUState field access detection is embedded into
"tcg-op.h", so that I have all the info after translating, not during
translated code execution (as then I would be unable to have all the
fetch info before actually executing translated code).


Still, if this is what you meant, I think it's way better than the
time-consuming and easily bitrotting task that I did.

The only drawback is that it would force all targets to produce the
fetch event after the whole instruction translation, and thus be forced
to do the x86 trick of moving buffers at the end of the instruction
translation. I hoped that this would be necessary only for x86, and that
other architectures would let me do it more easily before starting the
real translation (e.g., using the translation tables found in PowerPC).


Thanks,
        Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

[Prev in Thread] Current Thread [Next in Thread]