NetBSD Problem Report #44188

From dholland@eecs.harvard.edu  Fri Dec  3 07:56:32 2010
Return-Path: <dholland@eecs.harvard.edu>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 9A3F663B95F
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  3 Dec 2010 07:56:32 +0000 (UTC)
Message-Id: <20101203075549.9099FF9B1@tanaqui.eecs.harvard.edu>
Date: Fri,  3 Dec 2010 02:55:49 -0500 (EST)
From: dholland@eecs.harvard.edu
Reply-To: dholland@eecs.harvard.edu
To: gnats-bugs@gnats.NetBSD.org
Subject: gcov sucks
X-Send-Pr-Version: 3.95

>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.

Home	PR Database Search