From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNMGa-0005S2-W8 for qemu-devel@nongnu.org; Mon, 07 Nov 2011 05:17:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNMGX-0001Zd-Rf for qemu-devel@nongnu.org; Mon, 07 Nov 2011 05:17:24 -0500 Received: from mel.act-europe.fr ([194.98.77.210]:58765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNMGX-0001Us-FN for qemu-devel@nongnu.org; Mon, 07 Nov 2011 05:17:21 -0500 Message-ID: <4EB7B00B.5000000@adacore.com> Date: Mon, 07 Nov 2011 11:16:43 +0100 From: Fabien Chouteau MIME-Version: 1.0 References: <4639B135-B96A-43A0-B4FA-6DDCBE3FBA92@suse.de> <4EB1805F.6030701@adacore.com> <4EB26060.4060003@adacore.com> <20111104083652.GA5048@stefanha-thinkpad.localdomain> <87ipmzbub8.fsf@ginnungagap.bsc.es> In-Reply-To: <87ipmzbub8.fsf@ginnungagap.bsc.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Alexander Graf , "qemu-devel@nongnu.org Developers" , =?ISO-8859-1?Q?Llu=EDs_Vilanova?= On 04/11/2011 19:45, Llu=EDs Vilanova wrote: > Stefan Hajnoczi writes: >=20 >> 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 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. >=20 >> 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. >=20 >> 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. >=20 > 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 fr= om 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 us= er 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 defi= nitely > join the efforts on that side (e.g., I haven't yet went into the troubl= e 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, --=20 Fabien Chouteau