bin/44188: gcov sucks

Nice bug report:

>Number:         44188
>Category:       bin
>Synopsis:       gcov sucks
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 03 08:00:00 +0000 2010
>Originator:     David A. Holland
>Release:        NetBSD 5.99.41 (20101130)
>Organization:
>Environment:
System: NetBSD tanaqui 5.99.41 NetBSD 5.99.41 (TANAQUI) #32: Wed Dec 1 01:20:02 EST 2010 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386
Architecture: i386
Machine: i386
>Description:

gcov is primitive and really painful to use for trying to handle coverage of a real project.

The really serious problem is that there's no way to tell gcov that certain lines of code are expected to not be reached. Any real project has some and perhaps many of these, whether they're genuinely meant to be unreached (e.g. lines that contain "assert(0)") or they're currently unreached because of limitations in your test apparatus and you want to shut gcov up about them so you can concentrate on the stuff that's tractable.

It also only has rudimentary support for coping with basic blocks that are less than a full line of code. This often arises with expressions that contain && and ||... particularly assert expressions... and using this support makes the preceding problem markedly worse. This problem also arises if you have large macros; the invocation of the macro functions as one line with perhaps many basic blocks.

Other problems and annoyances include:

   - It does not seem to be able to cope with inline functions at all;
     the counts always come out zero.

   - Running a gcov-enabled binary makes a mess because it leaves
     dump files in your source tree.

   - Then, to run gcov you have to then hunt all these dump files
     down, and when you do it rewards you by leaving more files in
     your source tree.

   - The logging code in gcov-enabled programs is apparently not
     multiprocessor-safe; if you run your test suite in parallel it
     spews warnings and the output files apparently get corrupted.
     (I hate to think what happens if you try to use gcov with a
     multithreaded program.)

   - gcov itself spams the tty when it runs; the information it prints
     is not particularly useful to have on the tty.

>How-To-Repeat:

Try working with gcov on a project that's being actively developed.

>Fix:

Someone(tm) should write new coverage tools.

use autodie;

I rarely use perl but I'm sure I'll need this feature next time I dive into perl ;-)

-----Original Message-----
From: owner-tech@openbsd.org [mailto:owner-tech@openbsd.org] On Behalf Of Marc Espie
Sent: 04 October 2010 13:24
To: tech@openbsd.org
Subject: new perl

if you run into "fishy" perl scripts, newer perl includes (as standard)
autodie.

a simple
use autodie;

and at least, stupid stuff that NEVER CHECKS error returns from open() and
the like will die, die, die instead of struggling onwards...