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 <chout...@adacore.com> >>>> 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
