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

[Lluís]

Paul Brook writes:

>> 2) instrumenting i386 is extremely time-consuming (for the developer)
>> 
>> As my work is not tied to a specific target architecture, I was thinking of
>> shifting into PPC, as the ISA is pretty regular and that would certainly
>> make the process easier by just patching a small set of places in the
>> code.
>> 
>> ... 
>> The current example points are:
>> 
>> FETCH(vaddress, size, used_registers, defined_registers)

> Duplicating the insn decoder to determine which registers are accessed is not 
> a maintainable solution.

Right. On ISAs like PowerPC this can be solved much more easily, but in
x86 the implementation was based on manually searching all uses of the
register arrays, and adding the required call to set/define register.

Instead I could "hide" these structures in CPUState (not that I can
really do that in C), and provide two accessors that will do the job
instead.


> 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. Memory accesses are already automatically
handled by simply including a header that wraps the tcg_gen_qemu_ld/st
functions, and other events like privilege level change are very
localized, so bitrotting is much harder there.


> Anything solution that tries to separate CPU instrumentation/tracing
> from code generation is IMO fundamentally flawed and will rapidly
> bitrot beyond usefulness.

That's fundamentally correct, but I think that only on certaing events
and architectures.

As I said, this could be solved by forcing the programmer to use some
well-known interface for accessing, e.g., registers.


> 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.


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

Sorry, do what?


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