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

[Fabien Chouteau]

On 04/11/2011 19:45, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
> 
>> On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
>>> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
>>>> On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <address@hidden> wrote:
>>>>> On 29/10/2011 15:52, Alexander Graf wrote:
>>>> I took a quick peak at the qemu-trace.[ch] from couverture and it
>>>> looks along the lines of the instrumentation that others have been
>>>> doing too.  I hope you have time to propose the coverage
>>>> instrumentation for upstream QEMU.
>>>>
>>>
>>> I don't know much about other instrumentations in Qemu (pointers are
>>> welcome :), but what we have in couverture-qemu is not trivial,
>>> especially when it comes to MC/DC analysis. You should take a look at
>>> 201005-erts2.pdf if you want technical details.
> 
>> My impression was that the QEMU portion of instrumentation was fairly
>> simple - it writes out trace records at various interesting points
>> during guest execution in TCG.
> 
>> I think fancy analysis scripts do not have to be part of QEMU but they
>> could be added to scripts/ or put in a new contrib/ directory.
> 
> 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.

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

I think that generate a trace file that can be analyzed by any tool is a
better approach for coverage analysis.

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

Regards,

-- 
Fabien Chouteau