qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] GSoC mentor summit QEMU users session


From: Lluís Vilanova
Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session
Date: Mon, 07 Nov 2011 12:50:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Fabien Chouteau writes:

> On 04/11/2011 19:45, Lluís Vilanova wrote:
>> I've only had a brief look into the changes, but I think the mechanism I
>> implemented has a cleaner fit into QEMU, thanks to previous feedback from 
>> this
>> list.

> I don't know about your implementation, can you give more information?
> What type of analysis is supported (object, statement, decision, MC/DC)?
> Which language? And maybe you can post a link to your repository.

I'll be posting the patches once QEMU opens up for new commits other than
release stabilization. If this is too far away in time, please tell me.


>> It explicitly separates the tracing mechanism (in QEMU itself) from the 
>> specific
>> trace analysis (which resides in a separate library specified by the user at
>> compile time, where most of couverture would go).

> As I understand everything is compiled within Qemu, right?

> GNATcoverage seems even more separate. We use Qemu to generate an
> execution trace file and the coverage analysis tool is a totally
> separate program. You can add support for another language or implement
> your own coverage tool without recompiling (redistribute) Qemu.

The process is basically:

* Add trace events that can work during TCG code generation (e.g., start TB,
  start instruction fetch, memory access, etc.)

* Let the user select which trace events to instrument, including both "regular"
  trace events and TCG trace events (thus you instrument at both execution and
  translation time).

* The user provides her own implementation of the instrumented trace events.

As you can see, this system only gives you the hooks were code can be
inserted. Whether your hooks implement everything inside QEMU or just write a
trace file, that is up to you.


[...]
>> 
>> On the other hand, I have a complementary set of events, so we can definitely
>> join the efforts on that side (e.g., I haven't yet went into the trouble of
>> adding the begin/end TB or branch events).

> I don't know what do you mean by events, but we sure can join efforts on
> coverage with Qemu.

Well, my target is not code coverage, but generating events that can be used for
architecture simulation. In any case, there will surely be trace events that
we're both interested in (e.g., TB start and branch).


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]