mdr@reed.UUCP (Mike Rutenberg) (08/28/88)
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)? I tried posting this earlier, but it seemed to have failed. Mike mdr@reed (503)696-7284
roddyprep@deneb.ucdavis.edu (0000;0000071710;420;755;401;) (08/28/88)
In article <10147@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes: >I'm interested in finding a code coverage tool which Won't "prof" do what you want?
pardo@june.cs.washington.edu (David Keppel) (08/28/88)
[ mailer bounce, sorry for the post ] In article <10147@reed.UUCP> mdr@reed.UUCP (Mike Rutenberg) writes: >[ coverage tool for code that *has not* been executed ] Please write me directly if you don't get anything useable. ;-D on ( But then mine might not be useable, either ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
jinli@gpu.utcs.toronto.edu (jin li) (08/28/88)
> From: mdr@reed.UUCP (Mike Rutenberg) > Newsgroups: comp.lang.c > Subject: Execution profiling - CODE COVERAGE > Date: 27 Aug 88 20:57:00 GMT > > 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)? > ...... "prof -z" or "gprof -cz" will probably do what you want, but be sure to compile your program with appopriate option(s). -- Don't need fancy signature. jinli@gpu.utcs.toronto.edu
bill@proxftl.UUCP (T. William Wells) (08/29/88)
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)?
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.
---
Bill
novavax!proxftl!billhaahr@phoenix.Princeton.EDU (Paul Gluckauf Haahr) (08/29/88)
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
bright@Data-IO.COM (Walter Bright) (08/30/88)
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 [...] what portions of my program
<has not been executed during a run. Does anyone know
<of such beasts?
There is a program called CLUE available from OASYS that does exactly
this. We use it to verify that our test suites really test the program.ok@quintus.uucp (Richard A. O'Keefe) (08/30/88)
> From: mdr@reed.UUCP (Mike Rutenberg) > 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)? Many versions of UNIX have a tool called "tcov". For example, to analyse a program "fred.c", do cc -a fred.c # produces a.out and fred.d a.out # tcov fred.c # reads fred.c, fred.d, writes fred.tcov The "fred.tcov" file is a listing of the source files named in the "tcov" command, with each basic block preceded by a count of the number of times it was executed. Unexecuted basic blocks are preceded by "#####". A basic block is just a straight-line chunk of code. You can get counts for each statement too. I find that it is a big help in debugging. Several people mentioned "prof". Unfortunately, "prof" only tells you about procedures, not basic blocks, so isn't much use for finding out which parts of a program have been exercised, though System V comes with a marker macro you can use to break it down a bit.
ok@quintus.uucp (Richard A. O'Keefe) (08/30/88)
In article <3555@phoenix.Princeton.EDU> haahr@princeton.edu (Paul Gluckauf Haahr) writes: >tcov is a sun specific program. The first time I met tcov was in 1984. At the time, I was using Amdahl's port of Version 7 on an IBM 4331. Sun-specific?