Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!njin!princeton!phoenix!haahr
From: haahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr)
Newsgroups: comp.lang.c
Subject: Re: Execution profiling - CODE COVERAGE
Summary: tcov is from sun;  public domain equivalent available
Message-ID: <3555@phoenix.Princeton.EDU>
Date: 29 Aug 88 16:59:37 GMT
References: <10147@reed.UUCP> <659@proxftl.UUCP>
Reply-To: haahr@princeton.edu (Paul Gluckauf Haahr)
Organization: Princeton University, Princeton NJ
Lines: 44

in article <659@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes:
> In article <10147@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes:
> : I'm interested in finding a code coverage tool which
> : will let me know (ideally in terms of C constructs,
> : but assembler is fine) what portions of my program
> : has not been executed during a run.  Does anyone know
> : of such beasts (ideally running under unix)?

the unix prof utility can tell you which functions were called
and how often;  it's pretty easy to go from that information
to which functions weren't called.

> There is a utility, tcov, that does *exactly* what you want.  It
> was created, so the documentation claims, for just that purpose.
> I have it on our Sun; I do not know what other systems it is
> available on.

tcov is a sun specific program.  it instruments a c or fortran
source file with basic block counting code.  tcov is quite nice
to use, and produces rather useful profiling information as well
as test coverage.  mips provides similar profiling (as well as
far more detailed information) with pixie.  i wish more vendors
would provide tools like these.

peter weinberger wrote a similar program for eighth edition unix,
detailed in the second unix issue of the bell systems technical journal
(volume 68, number 8, october 84;  repackaged by prentice hall as
"readings in the unix system, volume 2," or somesuch), in the article
"cheap dynamic instruction counting."  pjw's program instruments
assembly language code and correlates with c or fortran source based
on .stab (debugger) entries.

his article discusses the reasons one would want to instrument
assembly code versus c (or other higher level language) code.

i have a public domain package modeled on weinberger's article.
it was submitted to comp.sources.unix on 8 may 1988, but i haven't
seen anything appear there in a while.  if you would like a copy,
drop me a line.  right now, the code runs on suns or vaxen, but it
is pretty easy to retarget for a new architecture.  some familiarity
with the target instruction set is required.

paul haahr
princeton!haahr or haahr@princeton.edu