Code Coverage Analysis in Windows Environment

[jpf_i]

I have a code that is written in both C++ and F90,
and I want to do a coverage analysis using CVF in Windows.
The C++ part of the code need not be evaluated,
but the F90 parts are distributed among hundreds of
F90 files. According to the help files on the profiler,
this is possible using a batch file, using the PREP,
PROFILE, and PLIST options. Could someone explain
conceptually how this works, what files are needed to
accomplish this, and how they depend on each other?
This is the first time I've tested code, so I'm kind
of lost. Any helpful resources (literature, etc.) and
references would also be greatly appreciated.

Thank you much,
jpf_i

[Jugoslav_Dujic]

"Programmer's guide/Using Visual Fortran Tools/Profiling Code from Command Line" chapter covers it rather thoroughly. It is a bit complicated, but then, it's too long to summarize in a short message either. First, on "link" tab of project settings, check "Enable profiling" and rebuild. Then, you can get the basic functionality from IDE (Tools->Profile), or write a batch file. Here's one I used for profiling a C++ exe + Fortran dll (if you have just one exe, it should be simpler):

@ECHO OFF
ECHO Preparing (step1)...
prep /FT /NOLOGO dmsshell.exe dmsapp.dll
ECHO Profiling...
profile /NOLOGO dmsshell.exe
ECHO Preparing (step2)...
prep /NOLOGO /IT dmsshell.pbt /IO dmsshell.pbo /OT output.pbt
ECHO Creating output file _profile.txt ...
plist /ST /NOLOGO /INDENT output.pbt >_profile.txt
del *.pbo
del *.pbt
del *.pbi

prep /LV sets line coverage (/FT above is for timing).

Hope this helps,
Jugoslav

[jpf_i]

I apologize for my ignorance in advance...
I have the executable for the code -- the final
part of the code was written in C++, so I don't
think that CVF could deal with it (or could it?).
The code depends on hundreds of *.f files (subroutines
and patches).
Is there a way to test the coverage of the "total"
code, given the executable and many *.f files, by
perhaps loading the *.f files into a project, and
then somehow specifying the executable?


Thank you again.

[jpf_i]

I should also mention the probably important fact
that the .exe file requires input files. I have
a set of input files, and I need to run them
all and determine which parts of the code were executed.

[Jugoslav_Dujic]

The profiler works (roughly, I won't look at docs exactly) like this:

- Compiler produces a exename.map file, which contains mapping of exe's assembly code to lines in your source code.
- PREP takes the .exe and .map and, depending on command-line option, digests both into a ._xe file; this is a copy of the executable, but it injects additional measuring code between lines
- PROFILE runs the ._xe file and produces a .pbo file on the basis of timing results produced by the injected code. Note that the ._xe behaves identically as the original .exe (e.g. it reads input files or produces a GUI or whatever). [Note, however, that if you run profiler from IDE, PROFILE doesn't "see" the working directory you set on project settings -- either copy the input files to ./Debug folder or change .exe location on Project/Settings/Link/Output file name.]
- PREP ran again with /M option digests .pbo and .pbt file and overwrites .pbt file; finally, PLIST creates a human-readable output.

The sample batch file I posted redirects PLIST's output into file _profile.txt which you can open in a text editor and analyse.

Jugoslav