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

[Fabien Chouteau <chouteau@adacore.com>]

On 07/11/2011 12:50, Lluís Vilanova wrote:
> 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.
> 

Interesting, what kind of analysis do you plan to perform with this?

> [...]
>>>
>>> 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).
> 

OK I thought you were talking about coverage. I'm not sure if and how we
can implement coverage using your events but for the moment both
features can cohabit.

-- 
Fabien Chouteau