Re: [Qemu-devel] [STATUS] static instrumentation

[Lluís]

Blue Swirl writes:

> The patches there seem to be fixes or small changes to your other
> patches. This makes any review very difficult.

Sorry, I'm really new to git, so I don't really know how to maintain and
"grow" an organized set of patches for review while I keep improving the
work.


> But I'm not sure the architecture is what we'd like to see integrated
> in QEMU, though I may have missed the whole picture because of the
> patch fragmentation problem. Before doing any work to possibly go
> further in wrong direction, please try to submit early some preview
> version for comments and review.

I can try to refactor the changes into a sensible set of patches, but
please read first the motivation of this work (below).


> Just as an example, perhaps the existing tracing framework could be
> extended to cover also your needs.

Well, for what I've seen of the tracing infrastructure ("tracing" from
here on), it is geared towards tracing qemu internal events (for
analyzing qemu performance), while static instrumentation
("instrumentation" from here on) is geared towards tracing guest events,
in order to analyze guest behaviour.

The reason for having static instrumentation points in the form of
macros (diverging from the approach taken in tracing) is that the most
common instrumentation points are invoked at code generation time. This
way the user can dynamically select which extra code to call and/or
generate (if any) on each of these points, with the addition that code
can be selected for regeneration when the instrumentation points need to
produce different code (e.g., no instrumentation, event counting,
sketchy trace generation, detailed trace generation, etc.).

So, I think they are geared towards different goals, although they are
indeed composable (e.g., the user can expand the instrumentation macros
into calls to the tracing infrastructure).

Wether or not this fits into upstream qemu is not for me to say, but it
provides the initial stepping stone that is commonly used in computer
architecture research (e.g., http://www.ptlsim.org or
http://sesc.sourceforge.net/), with the added bonus that qemu supports
multiple ISAs, as well as executing standalone applications and a
full-fledged system.

Of course, the simulator itself would be out of qemu, thus the macros :)


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