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
