From: "Alex Bennée" <alex.bennee@linaro.org>
To: Aleksandar Markovic <amarkovic@wavecomp.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [BUG] gcov support appears to be broken - solved?
Date: Mon, 05 Aug 2019 20:17:28 +0100 [thread overview]
Message-ID: <87y307ifqv.fsf@linaro.org> (raw)
In-Reply-To: <BN6PR2201MB1251F3D9E077A24F1E6106B6C6DA0@BN6PR2201MB1251.namprd22.prod.outlook.com>
Aleksandar Markovic <amarkovic@wavecomp.com> writes:
>>> #./configure --enable-gcov
>>> #make
>>> #make check
>>> #make coverage-report
>>>
>>> It seems that first three commands execute as expected. (For example,
>>> there are plenty of files generated by "make check" that would've not
>>> been generated if "enable-gcov" hadn't been chosen.) However, the
>>> last command complains about some missing files related to FP
>
>> So your failure mode is no report is generated at all? It's working for
>> me here.
>
> Alex, here is the thing:
>
> Seeing that my gcovr is relatively old (2014) 3.2 version, I upgraded it from git repo to the most recent 4.1 (actually, to a dev version, from the very tip of the tree), and "make coverage-report" started generating coverage reports. It did emit some error messages (totally different than previous), but still it did not stop like it used to do with gcovr 3.2.
>
> Perhaps you would want to add some gcov/gcovr minimal version info in our docs. (or at least a statement "this was tested with such and such gcc, gcov and gcovr", etc.?)
>
> Coverage report looked fine at first glance, but it a kind of
> disappointed me when I digged deeper into its content - for example,
> it shows very low coverage for our FP code (softfloat), while, in
> fact, we know that "make check" contains detailed tests on FP
> functionalities. But this is most likely a separate problem of a very
> different nature, perhaps the issue of separate git repo for FP tests
> (testfloat) that our FP tests use as a mid-layer.
I get:
68.6 % 2593 / 3782 62.2 % 1690 / 2718
Which is not bad considering we don't exercise the 80 and 128 bit
softfloat code at all (which is not shared by the re-factored 16/32/64
bit code).
>
> I'll try how everything works with my test examples, and will let you know.
>
> Your help is greatly appreciated,
> Aleksandar
>
> Fond regards,
> Aleksandar
>
>
>> Alex Bennée
--
Alex Bennée
next prev parent reply other threads:[~2019-08-05 19:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 10:39 [Qemu-devel] [BUG] gcov support appears to be broken Aleksandar Markovic
2019-08-05 11:02 ` Peter Maydell
2019-08-05 14:11 ` Alex Bennée
2019-08-05 15:36 ` Aleksandar Markovic
2019-08-05 15:39 ` Aleksandar Markovic
2019-08-05 18:56 ` [Qemu-devel] [BUG] gcov support appears to be broken - solved? Aleksandar Markovic
2019-08-05 19:17 ` Alex Bennée [this message]
2019-08-05 19:31 ` Aleksandar Markovic
2019-08-05 19:58 ` [Qemu-devel] ]Re: " Aleksandar Markovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y307ifqv.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=amarkovic@wavecomp.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.