polyspace-code-profiler

(System Command) Profile your source code for calculating C/C++ code coverage, code execution time, and memory use

Since R2023b

collapse all in page

Syntax

polyspace-code-profiler -instrument -instrum-dir instrumFolder -cov-metric-level covLevel [instrumOptions] -- compileCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -cov-metric-level covLevel -instrument-in-place -msbuild [instrumOptions] -- MSbldCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -exec-metric-level executionTimeLevel -prof-counter-size counterSize [instrumOptions] -- compileCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -exec-metric-level executionTimeLevel -prof-counter-size counterSize -msbuild [instrumOptions] -- MSbldCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -stack-metric-level memoryUseLevel -prof-counter-size counterSize [instrumOptions] -- compileCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -stack-metric-level memoryUseLevel -prof-counter-size counterSize -msbuild [instrumOptions] -- MSbldCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -sanitizer [-sanitizer-selection defectSelection] [-sanitizer-max-error-occurrences maxOccurrences] [instrumOptions]-- compileCommand
polyspace-code-profiler -instrument -instrum-dir instrumFolder -sanitizer [-sanitizer-selection defectSelection] [-sanitizer-max-error-occurrences maxOccurrences] -msbuild [instrumOptions] -- MSbldCommand
polyspace-code-profiler -run -instrum-dir instrumFolder -results-dir resultsFolder [runOptions] -- runCommand
polyspace-code-profiler -report -xml -report-dir reportDir [reportOptions] resultsPath
polyspace-code-profiler -report -html -report-dir reportDir [reportOptions] resultsPath
polyspace-code-profiler -report -xml -report-dir reportDir -filter-files filterFile[reportOptions] resultsPath
polyspace-code-profiler -report -html -report-dir reportDir -filter-files filterFile[reportOptions] resultsPath
polyspace-code-profiler -merge -results-dir mergedResult [mergeOptions] resultsToMerge
polyspace-code-profiler -merge -operation mergeOperation -results-dir mergedResult [mergeOptions] resultsToMerge
polyspace-code-profiler -convert -instrum-dir instrumFolder [convertOptions] binaryResultsPath
polyspace-code-profiler -justify-uncovered-dead-code -rationale reasonForDeadCode saResults [-target-filter-file customFilter] codeCoverageResults
polyspace-code-profiler -import-filters [-filter-file filterFile] sourceCovResult [-target-filter-file customFilter] targetCovResult
polyspace-code-profiler -version

Description

The polyspace-code-profiler system command instruments source code for code profiling and runs tests using the instrumented source code to collect code profiling results.

Instrument Source Files

Note

This Polyspace® command is available in the folder polyspaceroot\polyspace\bin. Here, polyspaceroot is the Polyspace installation folder, for instance, C:\Program Files\Polyspace\R2026a. To avoid typing the full path to this command, add this location to the PATH environment variable in your operating system.

polyspace-code-profiler -instrument -instrum-dir instrumFolder -cov-metric-level covLevel [instrumOptions] -- compileCommand instruments source files to calculate the code coverage metrics specified by covLevel.

In this step, Polyspace parses the source code, and then uses the compileCommand to compile the instrumented source files. If your code contains nonstandard code constructs, the parsing step might fail. Review the log to find which code constructs are unsupported. Before continuing, remove the unsupported construct.

example

polyspace-code-profiler -instrument -instrum-dir instrumFolder -cov-metric-level covLevel -instrument-in-place -msbuild [instrumOptions] -- MSbldCommand instruments a Microsoft® Visual Studio® project to calculate code coverage metrics specified by covLevel.

example

polyspace-code-profiler -instrument -instrum-dir instrumFolder -exec-metric-level executionTimeLevel -prof-counter-size counterSize [instrumOptions] -- compileCommand instruments the source files to calculate the execution time up to the level of details specified by executionTimeLevel. You cannot calculate more than one of the code coverage, execution time, or memory use metrics at a time.

example

polyspace-code-profiler -instrument -instrum-dir instrumFolder -exec-metric-level executionTimeLevel -prof-counter-size counterSize -msbuild [instrumOptions] -- MSbldCommand instruments a Microsoft Visual Studio project to calculate the execution time up to the level of details specified by executionTimeLevel. You cannot calculate more than one of the code coverage, execution time, or memory use metrics at a time.

example

polyspace-code-profiler -instrument -instrum-dir instrumFolder -stack-metric-level memoryUseLevel -prof-counter-size counterSize [instrumOptions] -- compileCommand instruments the source files to calculate the memory use up to the level of details specified by memoryUseLevel. You cannot calculate more than one of the code coverage, execution time, or memory use metrics at a time.

example

polyspace-code-profiler -instrument -instrum-dir instrumFolder -stack-metric-level memoryUseLevel -prof-counter-size counterSize -msbuild [instrumOptions] -- MSbldCommand instruments a Microsoft Visual Studio project to calculate the memory use up to the level of details specified by memoryUseLevel. You cannot calculate more than one of the code coverage, execution time, or memory use metrics at a time.

example

polyspace-code-profiler -instrument -instrum-dir instrumFolder -sanitizer [-sanitizer-selection defectSelection] [-sanitizer-max-error-occurrences maxOccurrences] [instrumOptions]-- compileCommand instruments the source files compiled by compileCommand for code sanitization.

polyspace-code-profiler -instrument -instrum-dir instrumFolder -sanitizer [-sanitizer-selection defectSelection] [-sanitizer-max-error-occurrences maxOccurrences] -msbuild [instrumOptions] -- MSbldCommand instruments the source files in the Microsoft Visual Studio project built by MSbldCommand for code sanitization.

Run Instrumented Test Executable

polyspace-code-profiler -run -instrum-dir instrumFolder -results-dir resultsFolder [runOptions] -- runCommand runs the test executable runCommand, collects code profiling data, and creates a Polyspace Test™ profiling results (.psprof) file populated with the collected data. You must create the instrumented text executable before invoking this command. After calling polyspace-code-profiler -instrument, link the instrumented source files and tests with the Polyspace Test run-time libraries to create the instrumented test executable.

example

Create Report

polyspace-code-profiler -report -xml -report-dir reportDir [reportOptions] resultsPath creates XML reports from code profiling results stored in resultsPath. The reports are stored in reportDir.

polyspace-code-profiler -report -html -report-dir reportDir [reportOptions] resultsPath creates HTML reports from code profiling results stored in the paths you specify in resultsPath. The reports are stored in reportDir.

example

polyspace-code-profiler -report -xml -report-dir reportDir -filter-files filterFile[reportOptions] resultsPath creates XML reports from code profiling results stored in the paths you specify in resultsPath. The reports are stored in reportDir.

polyspace-code-profiler -report -html -report-dir reportDir -filter-files filterFile[reportOptions] resultsPath creates HTML reports from code profiling results stored in the paths you specify in resultsPath. The reports are stored in reportDir.

example

Merge Results and Filter Files

polyspace-code-profiler -merge -results-dir mergedResult [mergeOptions] resultsToMerge merges the data results stored in resultsToMerge and creates a merged data file. This command also merges any filters associated with each set of result. The merged data file and filters are stored in mergedResult. You can generate different results in various separate runs and then use this command to merge the results into a single file.

example

polyspace-code-profiler -merge -operation mergeOperation -results-dir mergedResult [mergeOptions] resultsToMerge performs mergeOperation on the results and filters stored in resultsToMerge and creates a new files in mergedResult.

example

Convert Results

polyspace-code-profiler -convert -instrum-dir instrumFolder [convertOptions] binaryResultsPath converts the binary results in binaryResultsPath into .psprof files. You typically obtain the code profiling results in binary form when running your tests on a target.

Justify Uncovered Dead Code Using Polyspace Code Prover or Polyspace Bug Finder Result

polyspace-code-profiler -justify-uncovered-dead-code -rationale reasonForDeadCode saResults [-target-filter-file customFilter] codeCoverageResults creates a filter file to justify the uncovered code in codeCoverageResults that are reported as unreachable or dead code in saResults. The generated filter file contains the reasonForDeadCode as the value for the field rationale.

example

Import Filters

polyspace-code-profiler -import-filters [-filter-file filterFile] sourceCovResult [-target-filter-file customFilter] targetCovResult imports the filter with the same name as sourceCovResult and creates a filter for the results in targetCovResult. The imported filter has the same name as targetCovResult. If there are no filter files with the same name as sourceCovResult, then specify a filter file as filterFile.

example

Version

polyspace-code-profiler -version displays the version of the Polyspace Test product.

Examples

collapse all

The first step in calculating the code coverage of your code is to instrument your source files and produce the test executable from the instrumented code. See Algorithms.

Before instrumenting your code, compile the source and test files to make sure that there are no compilation errors. This example uses the GCC compiler (with compilation command gcc). The compilation command is:

gcc src/source.c src/tests.c PSTUNIT_SOURCE -I PSTUNIT_INCLUDE
Here, PSTUNIT_SOURCE and PSTUNIT_INCLUDE are locations of files and folders containing definitions of the Polyspace Test xUnit API macros. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

Instrument the source files used in the previous compilation command:

polyspace-code-profiler -instrument -limit-instrumentation-to src/ -instrum-dir instrums/ -cov-metric-level mcdc -- gcc -c src/source.c src/tests.c PSTUNIT_SOURCE -I PSTUNIT_INCLUDE
This command instruments the sources for calculating all available code coverage metrics and scopes the instrumentation to the src folder only. The results of this step, such as instrumented sources and traceability databases, are saved in the folder instrums/. The GCC compilation command uses the -c option to compile the files without linking the compiled object files.

After generating the compiled objects, link them with the precompiled run-time library provided with Polyspace Test. You can link the objects and the library using the gcc compiler.

gcc file.o test.o pstunit.o PSPROFILELIB
Here, PSPROFILELIB is an environment variable that contains the path to a precompiled run-time library containing the instrumentation macro definitions. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

This step generates the test executable, which you can run with polyspace-code-profiler -run to determine if the tests pass or fail and collect code profiling data. The default test executable name is a.exe in Windows® and a.out in Linux®.

The first step in calculating the execution time of your code is to instrument your source files and produce the test executable from the instrumented code. See Algorithms.

To create a test executable for calculating the execution time, instrument your code by using this syntax:

polyspace-code-profiler -instrument -limit-instrumentation-to src/source.c -instrum-dir instrums/ -cov-metric-level none -exec-metric-level profilingLevel -prof-counter-size counterSize -- gcc -c src/source.c src/tests.c PSTUNIT_SOURCE -I PSTUNIT_INCLUDE
Here, PSTUNIT_SOURCE and PSTUNIT_INCLUDE are locations of files and folders containing definitions of the Polyspace Test xUnit API macros. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

After successfully instrumenting the source code, link the compiled objects:

gcc file.o test.o pstunit.o PSPROFILELIB
Here, PSPROFILELIB is an environment variable that contains the path to a precompiled run-time library containing the instrumentation macro definitions. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

This step generates the test executable, which you can run with polyspace-code-profiler -run to determine if the tests pass or fail and collect execution time data. The default test executable name is a.exe in Windows and a.out in Linux.

The first step in calculating the memory use of your code is to instrument your source files and produce the test executable from the instrumented code. See Algorithms.

To create a test executable for calculating the stack memory use, instrument your code by using this syntax:

polyspace-code-profiler -instrument -limit-instrumentation-to src/source.c -instrum-dir instrums/ -stack-metric-level profilingLevel -prof-counter-size counterSize -- gcc -c src/source.c src/tests.c PSTUNIT_SOURCE -I PSTUNIT_INCLUDE
Here, PSTUNIT_SOURCE and PSTUNIT_INCLUDE are locations of files and folders containing definitions of the Polyspace Test xUnit API macros. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

After successfully instrumenting the source code, link the compiled objects:

gcc file.o test.o pstunit.o PSPROFILELIB
Here, PSPROFILELIB is an environment variable that contains the path to a precompiled run-time library containing the instrumentation macro definitions. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

This step generates the test executable, which you can run with polyspace-code-profiler -run to determine if the tests pass or fail and collect stack memory use data. The default test executable name is a.exe in Windows and a.out in Linux.

This example shows how to instrument your source code so that certain types of run-time errors are caught during test execution (code sanitizer profiling).

To create a test executable for sanitizer profiling, instrument your source code by entering this syntax:

polyspace-code-profiler -instrument -limit-instrumentation-to src/source.c -instrum-dir instrums/ -sanitizer -sanitizer-selection numeric -- gcc -c src/source.c src/tests.c PSTUNIT_SOURCE -I PSTUNIT_INCLUDE

Here, PSTUNIT_SOURCE and PSTUNIT_INCLUDE are locations of files and folders containing definitions of the Polyspace Test xUnit API macros. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

After successfully instrumenting the source code, link the compiled objects:

gcc file.o test.o pstunit.o PSPROFILELIB
Here, PSPROFILELIB is an environment variable that contains the path to a precompiled run-time library containing the instrumentation macro definitions. For more information, see Set Up C/C++ Testing and Code Profiling Using Self-Managed Builds.

This step generates the test executable, which you can run with polyspace-code-profiler -run to determine if the tests pass or fail and collect information on any run-time error occurrences. The default test executable name is a.exe in Windows and a.out in Linux.

The first step in calculating the code coverage of your code is to instrument your source files and produce the test executable from the instrumented code. Use the msbuild command at the Developer Command Prompt for Visual Studio to generate the instrumented test executable for the project. See Algorithms.

To follow this example, set up a Microsoft Visual Studio project. See Calculate Code Profiling Metrics in Microsoft Visual Studio.

After setting up your project, at the Developer Command Prompt for Visual Studio, navigate to the folder containing your project and enter:

polyspace-code-profiler -instrument -instrum-dir instrumfolder -cov-metric-level mcdc  -instrument-in-place -ignore-file "path_to_pstunit.cpp" -msbuild -- msbuild project.vcxproj /t:rebuild -p:platform=x64

  • The file pstunit.cpp is required to compile and link the tests. Calculating coverage for this file is not necessary. Exclude the file from instrumenting by using -ignore-file.

  • When instrumenting Visual Studio projects, you must specify the options -instrument-in-place and -msbuild.

  • Specify a writable instrumFolder to store the instrumented code and database.

  • To specify which code coverage metrics you want to calculate, set a value for -cov-metric-level. The default value is decision. To calculate coverage of all supported coverage metrics, use mcdc.

The folder instrumfolder stores the instrumented source files. The x64/Debug folder contains the instrumented test executable.

The first step in calculating the execution time for your Microsoft Visual Studio project is to instrument your source files and produce the test executable from the instrumented code. Use the msbuild command at the Developer Command Prompt for Visual Studio to generate the instrumented test executable for the project. See Algorithms.

To follow this example, set up a Microsoft Visual Studio project. See Calculate Code Profiling Metrics in Microsoft Visual Studio.

After setting up your project, at the Developer Command Prompt for Visual Studio, navigate to the folder containing your project and enter:

polyspace-code-profiler -instrument -instrum-dir instrumfolder -exec-metric-level detailed  -prof-counter-size 64 -instrument-in-place -ignore-file "path_to_pstunit.cpp" -msbuild -- msbuild project.vcxproj /t:rebuild -p:platform=x64

  • The file pstunit.cpp is required to compile and link the tests. Calculating coverage for this file is not necessary. Exclude the file from instrumenting by using -ignore-file.

  • When instrumenting Visual Studio projects, you must specify the options -instrument-in-place and -msbuild.

  • Specify a writable instrumFolder to store the instrumented code and database.

  • To specify the level of details for the calculation, set a value for -exec-metric-level. The default value is none. To calculate all supported execution time metrics, select detailed.

  • Because you specified -exec-metric-level, you must specify a value for -prof-counter-size. This option represents the width of the platform on which you run the test executable. Specify 64 as the value.

The folder instrumfolder stores the instrumented source files. The x64/Debug folder contains the instrumented test executable.

The first step in calculating the memory use of your Microsoft Visual Studio project is to instrument your source files and produce the test executable from the instrumented code. Use the msbuild command at the Developer Command Prompt for Visual Studio to generate the instrumented test executable for the project. See Algorithms.

To follow this example,set up a Microsoft Visual Studio project. See Calculate Code Profiling Metrics in Microsoft Visual Studio.

After setting up your project, at the Developer Command Prompt for Visual Studio, navigate to the folder containing your project and enter:

polyspace-code-profiler -instrument -instrum-dir instrumfolder -stack-metric-level detailed  -prof-counter-size 64 -instrument-in-place -ignore-file "path_to_pstunit.cpp" -msbuild -- msbuild project.vcxproj /t:rebuild -p:platform=x64

  • The file pstunit.cpp is required to compile and link the tests. Calculating coverage for this file is not necessary. Exclude the file from instrumenting by using -ignore-file.

  • When instrumenting Visual Studio projects, you must specify the options -instrument-in-place and -msbuild.

  • Specify a writable instrumFolder to store the instrumented code and database.

  • To specify the level of details for the calculation, set a value for -stack-metric-level. The default value is none. To calculate all supported memory use metrics, select detailed.

  • Because you specified -stack-metric-level, you must specify a value for -prof-counter-size. This option represents the width of the platform on which you run the test executable. Specify 64 as the value.

The folder instrumfolder stores the instrumented source files. The x64/Debug folder contains the instrumented test executable.

To calculate code coverage, execution time, or stack memory use, first you instrument the code and generate the instrumented test executable.

After creating the test executable, collect the code profiling data. See Algorithms.

If you use Microsoft Visual Studio, after instrumenting your code, at the Developer Command Prompt for Visual Studio, enter:

polyspace-code-profiler -run -instrum-dir instrumfolder -results-dir runfolder -- "x64/Debug/project.exe"

  • Specify the instrumfolder as the input to -instrum-dir. This folder must contain the instrumented code.

  • Specify a writable folder runfolder as the input to -results-dir. The run command generates the results file ( .psprof) from the instrumented code, and stores it in the runfolder.

  • Specify the instrumented test executable to run. In this example, this test executable is in x64/Debug.

If you are using a gcc compiler, at the command line, enter:

polyspace-code-profiler -run -instrum-dir instrums/ -results-dir runfolder -- a
Here, a is the instrumented test executable file. You generate the instrumented test executable a by compiling the instrumented source files.

This command generates the code profiling results and saves the resulting .psprof file in the folder runfolder.

After generating code profiling data by running an instrumented test executable, generate HTML code profiling reports containing the code profiling metrics by using the polyspace-code-profiler -report command. For details about instrumenting source code and running the test executable, see:

If you are using Microsoft Visual Studio, at the Developer Command Prompt, enter

polyspace-code-profiler -report -html -report-dir reportfolder runfolder

  • Specify runfolder as the resultsPath.

  • Specify reportfolder as the input to -report-dir.

  • Specify the format of the report as -html.

If you are using gcc, enter the preceding command at a regular command line terminal.

To view the report, open the HTML file in reportfolder.

You can generate an HTML code coverage report by using the polyspace-code-profiler -report command.

After reviewing the code coverage results, you can justify or exclude certain results. Create a filter and then specify it as an input to polyspace-code-profiler -report to generate a filtered result.

Create a filter. Say you have a function divide():

double divide(double up, double down) {
  if (down != 0) {
    return up / down;
  } else {
    return 0;
  }

}
Here, the false outcome of the decision down!=0 results in a divide-by-zero error. The else branch is defensive code. To justify the false outcome of this decision, create a filter, say, filter.psprof.filter:
<?xml version="1.0" encoding="utf-8"?>
<filter>
   <rule type="DECISION" fileName="divide.c" functionName="divide" expr="down!=0" index="1" source="USER" mode="JUSTIFIED" rationale="beause DBZ"/>
    ...
</filter>
For details about creating filters, see Improve or Justify Missing Code Coverage Results.

To create a filtered report, at the command prompt, enter:

polyspace-code-profiler -report -html -report-dir reportfolder -filter-files "filter.psprof.filter" runfolder

Here,

  • The folder runfolder contains the unfiltered results in a .psprof file.

  • The folder reportfolder contains the filtered report.

To view the report, open the HTML file in reportfolder. The report contains a section that describes filtered code and rationale you specify for justifying the filtered code. The justified code coverage results are highlighted.

You can generate code coverage results (.psprof) multiple times and then generate a combined report based on all the results. Merge the code coverage results into a single .psprof file before you generate the report.

Generate two sets of code coverage data from your C/C++ source.

Store the coverage results in two folders, say runFolder1 and runFolder2. Then, at the command line, enter:

polyspace-code-profiler -merge -results-dir mergedFolder runFolder runFolder2
If you use Microsoft Visual Studio, enter the preceding command at the Developer Command Prompt for Visual Studio.

The data from runFolder1 and runFolder2 is combined into a single .psprof in the folder mergedFolder.

Generate the report from the combined .psprof file. At the command line, enter:

polyspace-code-profiler -report -html -results-dir report mergedFolder
The HTML report is stored in the report folder.

You can generate code coverage and profiling results (.psprof) for code variants and then generate a combined report based on all the results. Merge the results into a single .psprof file before you generate the report.

Consider this code:

#ifdef LINUX_FLAG
// Code for Linux os
//...
#elif WINDOWS_FLAG
// Code for Windows os
//...
#endif
In this code, an ifdef switch is used that allows you to compile the code differently for Windows and Linux environments.

Generate code coverage and profiling results. Store the coverage results in two folders, say Windows and Linux. Then, at the command line, enter:

polyspace-code-profiler -merge -operation aggegate-variants -results-dir Aggregate Windows Linux
If you use Microsoft Visual Studio, enter the preceding command at the Developer Command Prompt for Visual Studio.

The data from Windows and Linux are combined into a single .psprof in the folder Aggregate.

Generate the report from the combined .psprof file. At the command line, enter:

polyspace-code-profiler -report -html -results-dir report Aggregate
The HTML report is stored in the report folder.

If you generate code profiling data without invoking the polyspace-code-profiler -run command, Polyspace Test stores the generated results in a .bin file. For instance, you might be running the test executable on a target where the polyspace-code-profiler -run command is not available. In such cases, convert the generated results in a .bin file into a .psprof file before generating the report.

To convert the .bin file to a .psprof file, at the command line, enter

polyspace-code-profiler -convert -instrum-dir instrumFolder -results-dir conFolder filename.bin

Here,

  • instrumFolder contains the instrumented source files.

  • conFolder is the folder where Polyspace Test stores the generated .psprof file.

  • filename.bin is the name of the .bin file.

See Calculate C/C++ Code Profiling Metrics by Using xUnit API-Based Tests on Target.

If your source files contains unreachable code, create a filter to automatically justify the uncovered unreachable code by leveraging Code prover results.

First, calculate the code coverage results of your source.

If your code contains unreachable code, they test cases cannot cover the unreachable code. To identify the unreachable code, run a Code Prover analysis. For instance, at the command line, enter:

polyspace-code-prover -sources source.c -main-generator -results-dir CPresults
After the analysis completes, the Code Prover results are stored in CPresults/ps_results.pscp.

To generate a filter that justifies the missing coverage of the identified unreachable code, at the command line, enter:

polyspace-code-profiler -justify-uncovered-dead-code -rationale "Dead_Code_found_by_CP" CPresults/ps_results.pscp output_run.psprof
Here, the file output_run.psprof is the code coverage results for your source code. The filter file output_run.psprof.filter is stored in the same folder as output_run.psprof.

To create a code coverage report that filters out and justifies the unreachable code, at the command line, enter:

polyspace-code-profiler -report -html -report-dir reportfolder -filter-files "output_run.psprof.filter" runfolder
Here,

  • The folder runfolder contains the files output_run.psprof and output_run.psprof.filter.

  • The folder reportfolder contains the filtered report.

After modifying the tests for your code, you can evaluate the changes in code coverage caused by the modifications in the tests. To evaluate the change in the code coverage, perform a diff operation.

Consider the function foo and its test cases.

foo()Test Cases
int foo(int A, int B, int C){
    if(A||B&&C)
        return 1;
    return 0;
}

  • foo(0,0,1) == 0

  • foo(0,1,1) == 1

Calculate the code coverage for these tests and store the resulting results (.psprof) file in the folder RunA. These test cases result in a 67% Condition Coverage and 33% Modified Condition/Decision Coverage (MCDC) Coverage.

To improve the code coverage, you can add these test cases:

  • foo(0,1,0) == 0

  • foo(1,0,1) == 1

The new test cases changes the code coverage. Calculate the new code coverage and store the new results (.psprof) file in runB.

To see the impact of the new tests, calculate the diff between runB and runA. At the command line, enter:

polyspace-code-profiler -merge -operation diff -results-dir diffDir runB runA
The resultant .psprof file is stored in the folder diffDir.

Create a report from the results in diffDir. The report indicates that the new tests add 33% more condition coverage and 33% more MCDC coverage.

After updating your source code, you can import your filters from the previous code coverage calculations to your new code coverage calculation. Use the -import-filter option to import the filter from your previous results.

Consider the function foo(). This function has a condition that is always false.

foo()Test Cases
int foo(int ch){

    int table[5];

    for(int i=0;i<=4;i++){
        table[i]=i^2+i+1;
    }

    if(table[ch]>100){ /* Always false */
         return 0;  
    }
    return table[ch];
}

  • foo(0) == 1

  • foo(1) == 3

To justify missing coverage of this condition, say you have a filter filt.psprof.filter:

<?xml version="1.0" encoding="utf-8"?>
<filter>
    <rule type="DECISION" fileName="divide.c" functionName="foo" expr="table[ch]&gt;100" index="2" mode="JUSTIFIED" rationale=""/>
</filter>

Calculate the code coverage and store the results in the folder Run1. To generate the filtered report, at the command line, enter:

polyspace-code-profiler -report -html -report-dir reportFolder  -filter-files filt1.psprof.filter  Run1
In the HTML report, the condition table[ch]>100 is justified.

Say you modified the function foo() to have a new condition:

int foo(int ch){

    int table[5];
    for(int i=0;i<=4;i++){
        table[i]=i^2+i+1;
    }
    if(table[ch]<0){return -1;} //New condition
    if(table[ch]>100){ 
         return 0;  
    }
    return table[ch];
}
Calculate the code coverage of the modified source code and store the results in Run2. The filter filt.psprof.filter no longer justifies the known unreachable code.

To import filt.psprof.filter so that it is applicable to the modified source code, at the command line, enter:

polyspace-code-profiler -import-filter -filter-file filt.psprof.filter Run1 Run2
In the folder Run2, a new filter is generated:

output_run.psprof.filter
<?xml version="1.0" encoding="utf-8"?>
<filter>
    <rule type="DECISION" fileName="divide.c" functionName="Return_From_Table" expr="table[ch]&gt;100" index="3" source="IMPORT" mode="JUSTIFIED" rationale=""/>
</filter>

The index is now 3 instead of 2.

After importing the filter, generate the filtered report. The unreachable code is now justified.

Input Arguments

collapse all

Instrument Source Files

Path to folder containing instrumented sources and a traceability database (database listing files, functions, decisions, and other elements that are instrumented for code profiling). This folder:

  • Must be provided as a results folder in the instrumentation step:

    polyspace-code-profiler -instrument -instrum-dir instrumFolder

  • Must be provided as input to the code profiling data collection step (and must be the same as the results folder in the previous instrumentation step):

    polyspace-code-profiler -run -instrum-dir instrumFolder
    Or:
    polyspace-code-profiler -convert -instrum-dir instrumFolder

  • Must be different than the folder where you keep the source files that you specified as the input to -limit-instrumentation-to.

You must have write access to this folder. if you do not have permission to write in this folder, the instrumentation process fails.

Example: -instrum-dir "C:\src\coverage_data\"

Compiler command specified exactly as you use to compile your source code. The instrumentation step extracts all source filenames from this compile command.

Example: gcc src.c, g++ src.cpp

msbuild command specified exactly as you use to build your Visual Studio project. The option -instrument-in-place is required when you instrument a Visual Studio project.

Example: msbuild project_name.vcxproj /t:Rebuild -p:platform=x64

Polyspace profiles your code to calculate various test coverage metrics. To enable the different coverage levels, use these values:

If you specify a value for -cov-metric-level, then you cannot specify -exec-metric-level at the same time.

Example: -cov-metric-level mcdc

Polyspace profiles your code to calculate the execution time at different levels of details. To select the different levels, use these values:

  • none — Disables collecting execution time data.

  • minimal — Enables calculating the Total time.

  • standard — Enables calculating Total time, Self Time, and Count.

  • detailed — Enables calculating Total time, Self Time, and Count, and Max.

See Execution Time.

Polyspace Test does not support simultaneously calculating more than one among code coverage, execution time, and memory use.

Example: -exec-metric-level standard

Polyspace profiles your code to calculate the memory use at different levels of details. To select the different levels, use these values:

  • none — Disables collecting memory use.

  • minimal — Enables calculating the maximum (max) stack memory usage of a function among its different execution path.

  • standard — Enables calculating the stack memory use by each function (self) as well as the max value for each function.

  • detailed — Enables calculating max, self, and Count values.

See Memory Use.

Polyspace Test does not support simultaneously calculating more than one among code coverage, execution time, and memory use.

Example: -stack-metric-level standard

This option represents the width of the platform on which you run your test executable. This option is required if you specify -exec-metric-level or -stack-metric-level. If your target platform is narrower than 32 bits, specify 32 as the value.

Example: -prof-counter-size 32

This option specifies the types of defects that must be covered during code sanitization. Specify one or more of these values in a comma-separated list when instrumenting your source files for code sanitization:

  • numeric: Instruments only those expressions that might cause numeric errors such as numeric overflows and division by zero.

  • memory: Instruments only those expressions that might cause static or dynamic memory-related errors such as array or pointer access out of bounds.

If you omit this option, the value implicitly selected is numeric, memory.

Example: -sanitizer-selection numeric

This option specifies the maximum number of error occurrences that must be reported by the code sanitizer before it stops reporting errors. If you omit this option, there is no ceiling on the error reporting and all errors found are reported.

If the binary created using instrumented sources takes a long time to run, try setting a lower value for this option.

Example: -sanitizer-max-error-occurrences 100

File Instrumentation Options

OptionArgumentDescription
-limit-instrumentation-toPath to folder

Limit instrumentation to the specified folder and exclude other files.

This option works exactly opposite to the -ignore-dir option. If you specify both options on the same folder, you see an error. If you specify -limit-instrumentation-to on a folder and -ignore-dir on a subfolder of that folder, the subfolder is ignored.

Example: -limit-instrumentation-to src

-ignore-dirPath to folder

Path to folders containing sources that must not be instrumented.

This option works exactly opposite to the -limit-instrumentation-to option. If you specify both options on the same folder, you see an error. If you specify -ignore-dir on a folder and -limit-instrumentation-to on a subfolder of that folder, the subfolder is instrumented.

Example: -ignore-dir src/3rdparty/

-ignore-filePath to file

Path to file that must not be instrumented. You can specify this option multiple times.

Example: -ignore-file src/framework.c

-ignore-fcnFunction name

Function that must not be instrumented.

For functions that are part of a namespace, use the fully qualified name, including the scope resolution operator.

Example: -ignore-fcn main

-ignore-fcn-callFunction name

Ignore the coverage of calls to one or more functions.

For functions that are part of a namespace, use the fully qualified name, including the scope resolution operator. If you specify a function with multiple overloads, calls to all overloads of the function are ignored.

When you specify a function as an input to this option, the content of the function is instrumented, but the call to the function is not instrumented.

Example: -ignore-fcn-call foo

-fail-if-errorN/A

Whether code instrumentation must stop on build errors.

By default, code instrumentation can continue if your build command invokes a compiler and the compilation is successful (even if there are other build errors later). Use this option if you want the code instrumentation to stop on any kind of build error.

-instrument-in-placeN/A

Whether the source files must be instrumented in place.

By default, a copy of the source files are instrumented. The instrumentation step:

  1. Parses the build command to identify the source files.

  2. Copies the source files into instrumFolder.

  3. Instruments the copied source files to generate the traceability data base.

In this process, Polyspace Test does not modify your original source file.

If the source files cannot be identified by parsing the build command, use the option -instrument-in-place to instrument the original sources themselves.

If you specify this option, then the source files must be in a writable folder. If you specify this option without having write permissions for the source files, Polyspace exits with an error.

To avoid data races and compilation errors, using this option is not recommended when instrumenting the same source file multiple times in parallel.

-compactN/A

Selecting this option might reduce the amount of memory required to run the test executable.

By default, when instrumenting your code for code coverage calculations, Polyspace allocates an unsigned 32-bit integer counter to count the number of times a coverage outcome is achieved. When you specify this option, Polyspace allocates only a single bit to record whether a coverage outcome was achieved or not.

For more information, see Enable compact mode for coverage calculation (-compact).

-cov-relboundN/A

Specify this option to enable computation of relational boundary coverage.

-cov-relbound-abs-tolNumberAbsolute tolerance value for relational boundary coverage. A warning is shown if you specify this option without specifying -cov-relbound.
-cov-relbound-rel-tolNumberRelative tolerance value for relational boundary coverage. A warning is shown if you specify this option without specifying -cov-relbound.
-sources-encoding

The encoding method of your source code.

Valid values for this options include:

  • system: Specifies the encoding method as the default encoding method of the operating system you use.

  • auto: Polyspace Test uses internal heuristics to determine the encoding method used in your source file from its content.

  • shift-jis: Specifies the source code encoding as Shift JIS (Shift Japanese Industrial Standards). This encoding method is used for encoding Japanese language.

  • iso-8859-1: Specifies the encoding as ISO/IEC 8859-1. This ASCII-based character encoding method encodes "Latin alphabet no.1", which consists of 191 characters from the Latin script.

  • windows-1252: Specifies the encoding as Windows-1252. This single byte encoding method is used by some legacy Windows components for encoding European language characters.

  • UTF-8: Specifies the encoding as UTF-8. This encoding method encodes all Unicode code points by using up to four 8-bit blocks.

-sources-encoding-listN/AUse this option to obtain a complete list of all source encoding supported by Polyspace Test. When you use this option, the log contains a message that lists all supported source encoding.

Other Options

OptionArgumentDescription
-options-filePath to text file

Path to a text file containing one option per line.

Example: -options-file options\instrum_options.txt

-verbose 

Whether the instrumentation command produces a more detailed output on the console (with individual steps of instrumentation broken down).

Use this option for troubleshooting purposes. By default, if an error occurs during instrumentation, you see the error message. If you also want to see the phases of instrumentation that completed before the error, use this option.

-help 

Use this option to see the options available with polyspace-code-profiler -instrument.

Run Instrumented Test Executable

Command to run the instrumented test executable. This test executable is previously created by linking object files from:

  • Instrumented sources

  • Tests

  • Library that defines coverage-related macros.

A precompiled version of the static library libmwpsprofile_cli_runtime is provided in polyspaceroot\polyspace\psrpofile\lib. Depending on your operating system, use the precompiled library from the appropriate subfolder. Here, polyspaceroot is the Polyspace installation folder.

Example: testrunner.out, testrunner.exe

The run command executes the instrumented source code and generates a results (.psprof) file containing the code profiling data. The resultsFolder contains the .psprof file and other outputs of the run command. Use this folder as the resultsPath to generate a report.

Example: -result-dir ../results

Options for Test Execution, Code Profiling Data Collection, and Storage

OptionArgumentDescription
-results-dirPath to folder

Path to folder where code profiling data is stored after running the test executable.

Example: -results-dir results/

-working-dirPath to folder

Path to folder from which the test executable must be run.

Example: -working-dir execs/

-results-nameString

Name of the output without the extension. The default name is 'output_run'.

Example: -results-name new_results

-return-code-fail-valueintSpecify the value that the -run commands returns if there are no errors in the source code, but the -run command fails to produce a results (.psprof) file. If you do not specify this option, the -run command returns the default value 253 in such a situation.
-return-code-from-app N/A

When you specify this option, the run command returns different values for different errors.

ErrorReturn value
Error in command syntax1
Error in your source codeError code returned by the test executable.
No error in command syntax and no Error in code, but a results (.psprof) file is not generated.Value specified by -return-code-fail-value. If no value if specified as -return-code-fail-value, the -run command returns the default value 253.
No error in command syntax and no Error in code, and a results (.psprof) file is generated.The value returned by the test executable.

If you do not specify this option, the run command returns a single value 1 in case of any failure, and a single return value 0 if a .psprof file is generated.

Other Options

OptionArgumentDescription
-options-filePath to text file

Path to a text file containing one option per line.

Example: -options-file options\run_options.txt

-do-not-remove-duplicated 

By default, if multiple instrumented source files correspond to the same source file, Polyspace Test considers the latest instrumented source files and traceability database when profiling the code.

Use this option to consider the older instrumented source files as well when profiling the code. For instance, you might have instrumented two versions of the same source file with different options. Using this file allows you to retain the traceability files for both versions and, for instance, include both versions of the results in your report.

-verbose 

Whether the run command produces a more detailed output on the console.

Use this option to see the results of test execution along with code profiling data collection. By default, Polyspace Test suppresses the results of test execution. To see those results, you have to run the test executable by itself (without the polyspace-code-profiler -run command). If you want to see test execution results and collect code profiling data in one step, use the -verbose option.

-help 

Use this option to see the options available with polyspace-code-profiler -run.

Create Report

Path to results (.psprof) files or folders containing .psprof. If you specify path to one or more folders containing .psprof files, a report is generated from each .psprof files in those folders.

The results files are generated by executing the run command, either on host or on a target.

  • For execution on a host, the test execution step can be run on its own or preceded by the command polyspace-code-profiler -run. If the execution step runs on its own, the results file is a .bin file. Otherwise, the results file is a .psprof file. These files can be located in resultsFolder after you execute the run command.

  • After execution on target, the results file is a .bin file. Transfer the .bin file back to the host for conversion and report generation.

If the results file is a .bin file, you provide the folder containing this file to the command polyspace-code-profiler -convert to generate a .psprof file. You then provide the path containing a .psprof file to the command polyspace-code-profiler -report for generating HTML reports.

Example: ../results

After you run the report command, the generated reports are stored in the folder reportDir.

Example: -report-dir ../reportFolder

Path to a filter (.psprof.filter) file. To justify or exclude certain coverage results in the generated report, you create a .psprof.filter filter file and specify the path to the file as filterFile. If you do not specify a specific filterFile, Polyspace Test uses the default filter file. Typically, the default filter file is stored in the same folder as the .psprof file.

Example: -filter-files Filter/filterFile.psprof.filter

Reporting Options

OptionArgumentDescription
-report-dirPath to folder

Path to folder where Polyspace Test stores the generated reports.

Example: -report-dir reports/

-add-environment-infoPath to file

Path to JSON file specifying environment information to be added to the report. Use this option if you want to save environment information in your profiling result reports.

The JSON file has the following structure: 

{
    "BuildConfiguration": "<nameOfConfiguration>",
    "ConfigurationDescription": "<descriptionOfConfiguration>",
    "Toolchain": "<nameOfToolchain>",
    "Board": "<nameOfBoard>"
}
You can set these values as desired to reflect your profiling configuration.

Note that if you generate a report using a Polyspace Platform project, the same values are automatically populated from your project configuration and you do not require to specify an additional file for the environment information. For more information on the values expected for the JSON keys, see Structure of HTML Reports Generated from C/C++ Test Results.

Example: -add-environment-info env_info.json

Other Options

OptionArgumentDescription
-options-filePath to text file

Path to a text file containing one option per line.

Example: -options-file options\report_options.txt

-verbose 

Whether the run command produces a more detailed output on the console.

Use this option for troubleshooting purposes. By default, if an error occurs during the report generation, you see the error message. If you also want to see the steps that completed before the error, use this option.

-help 

Use this option to see the options available with polyspace-code-profiler -report.

Merge Results

Path to .psprof files or folders containing the .psprof files. If you specify the path to one or more folder, all .psprof files in those folders are merged. You generate the .psprof data files in previous analyses. For example, if you execute the polyspace-code-profiler -run command, the .psprof is stored in the resultsFolder. If you have .bin files instead of .psprof files, use polyspace-code-profiler -convert to generate .psprof files from the .bin files.

Example: ../previous_results

Path to folder where the merged .psprof file is stored.

Example: -result-dir merged_results/

Specify what operation to perform between two results files.

  • union: Polyspace Test performs a union between the input results in resultsToMerge. The result file in mergedResults contains the aggregate of the input files. This operation can be performed on two or more input folders. If the input folders contain filter files, Polyspace moves the most recent filter files into the folder mergedResults.

  • diff: Polyspace Test performs a diff operation between the input results in resultsToMerge. The results file contains the difference calculated by excluding the results from the second folder in resultsToMerge from the first folder in resultsToMerge. This operation is sensitive to the order in which you specify the input folders. This operation can be performed only between two input folders. If the input folders contain filter files, the filter from the first folder is moved into mergedResults

  • intersect: Polyspace Test performs an intersection between the results in resultsToMerge. The resultant results file contains the results that are present in all input folders. This operation can be performed on two or more input folders. If the input folders contain filter files, Polyspace moves the most recent filter files into the folder mergedResults.

  • aggregate-variants: Polyspace Test aggregates results from different code variants. Specify the results from the code variants in resultsToMerge. The results file in mergedResults combines the code coverage and profiling results from the different variants and provide a combined overview.

Example: -operation diff

Merging Options

OptionArgumentDescription
-results-nameName of the produced results file

Name of the merged results file without the extension. The default name is 'output_merged'.

Example: -results-name merged_results

Other Options

OptionArgumentDescription
-options-filePath to text file

Path to a text file containing one option per line.

Example: -options-file options\report_options.txt

-verbose 

Whether the run command produces a more detailed output on the console.

Use this option for troubleshooting purposes. By default, if an error occurs during the report generation, you see the error message. If you also want to see the steps that completed before the error, use this option.

-help 

Use this option to see the options available with polyspace-code-profiler -report.

Convert Results

Space-separated .bin file paths or paths to folder(s) containing coverage results in .bin files. If you provide file paths and your files do not have the .bin extension, the polyspace-code-profiler -convert command attempts to convert them anyway.

If you convert more than one .bin file, when you convert the results, the coverage data in all the .bin files are accumulated into a single .psprof file. For more information, see Accumulate Code Coverage from Separate Test Executions.

Example: ../binaryFolder

Converting Options

OptionArgumentDescription
-results-dirPath to folder

Path to folder where the converted result is stored.

Example: -results-dir converted_results/

-results-nameName of the converted results file

Name of the converted results file without the extension. The default name is 'output_converted'.

Example: -results-name converted_results

Other Options

OptionArgumentDescription
-options-filePath to text file

Path to a text file containing one option per line.

Example: -options-file options\report_options.txt

-verbose 

Whether the run command produces a more detailed output on the console.

Use this option for troubleshooting purposes. By default, if an error occurs during the report generation, you see the error message. If you also want to see the steps that completed before the error, use this option.

-do-not-remove-duplicated 

By default, if multiple instrumented source files correspond to the same source file, Polyspace Test considers the latest instrumented source files and traceability database when profiling the code.

Use this option to consider the older instrumented source files as well when profiling the code. For instance, you might have instrumented two versions of the same source file with different options. Using this file allows you to retain the traceability files for both versions and, for instance, to include both versions of the results in your report.

-help 

Use this option to see the options available with polyspace-code-profiler -report.

Justify Dead Code using Polyspace Bug Finder or Polyspace Code Prover Result

Provide a reason why some code in your source files is unreachable and thus cannot be covered by your tests. In the report, the coverage results of the uncovered code is then justified with the provided rationale.

Example: 'Justifying unreachable defensive code'

Path to a Code Prover results file (.pscp) or Bug Finder results file (.psbf). If the static analysis flags some code as unreachable, Polyspace Test justifies the coverage results of these unreachable code.

Example: ../foo.psbf

Path to code coverage results (.psprof) files. This file contains the unfiltered code coverage results of your code.

Example: ../foo.psprof

By default, Polyspace Test applies the default filter on the code coverage result. The default filter is located in the same folder as the results (.psprof) file. To specify a different filter, specify the path to the filter file as customFilter.

Example: ../bar.psprof.filter

Import Filters

Import the filter that has the same name as the .psprof file from this folder. For instance, you might modify your source code after reviewing the code coverage report. When calculating the code coverage of the updated code, import your previously used filter to the new calculation. Specify the previous results as the sourceCovResult and the new results as targetCovResult.

Example: -import-filters source.psprof target.psprof

Apply the filter imported from sourceCovResult to this result. For instance, you might modify your source code after reviewing the code coverage report. When calculating the code coverage of the updated code, import your previously used filter to the new calculation. Specify the previous results as the sourceCovResult and the new results as targetCovResult

Example: -import-filters source.psprof target.psprof

Limitations

  • The command polyspace-code-profiler does not support multithreaded code.

  • When you instrument your code by using the polyspace-code-profiler -instrument command, Polyspace converts the encoding of your source files to utf-8 and then inserts instrumentation macros in the converted source files. If your code relies on the raw binary values of the source files, the change in encoding can result in unexpected result.

  • The instrumentation process might prevent some compiler optimization, such as inlining of functions. The execution time of the instrumented code can be larger than the execution time of the uninstrumented code. The execution times calculated by Polyspace Test represents the upper limit of the execution time of your code.

  • The instrumentation process might increase the stack memory use of your function. The memory use calculated by Polyspace Test represents the upper limit of the memory use of your code.

  • Because C++ compilers call destructors before a function exit, the calculated memory use of a function is larger if you compile your code using a C++ compiler.

  • Polyspace Test cannot calculate the stack memory consumed by the entry-point function. The self and max value of the memory use metric for entry-point functions are reported as 0.

  • When calculating the execution time and memory use of C++ code, polyspace-code-profiler ignores these functions:

    • Functions that throw an exception.

    • Functions that handle an exception thrown elsewhere in the call stack.

  • When calculating the memory use, Polyspace Test ignores variable length arrays (VLA).

  • If you use a function that is not instrumented, Polyspace Test does not measure the code coverage, execution time, or memory use of the function. When calculating the memory use of functions that call such uninstrumented functions, the memory use of the uninstrumented functions are ignored.

Tips

  • If you want to exclude specific portions of your source code from code profiling, use the pragma tmw code_instrumentation off. When Polyspace Test encounters this pragma, it stops instrumenting the source code until it encounters the pragma tmw code_instrumentation on. For instance, in this code, the call to foo is excluded from code profiling:

    void bar(){
	//...
	#pragma tmw code_instrumentation off 
	foo();
	#pragma tmw code_instrumentation on
	//....
}

  • Instead of typing the polyspace-code-profiler commands for instrumentation, run, and reporting directly at the command line, you can enter them in a makefile and execute make at the command line. For an example makefile, see Calculate Code Profile by Using Makefile.

    You can also generate such a makefile using generators such as CMake. For instance, when generating a makefile with the cmake command, in addition to your usual CMake flags, define the following variables using cmake options:

    • CMAKE_C_COMPILER_LAUNCHER: Set this variable to the full path of the polyspace-code-profiler command. Add appropriate polyspace-code-profiler options, separating the command from options and options from each other, using a ; separator.

      For instance, to construct the command:

      polyspace-code-profiler -instrument -instrum-dir instrumFolder -- gcc files
      You can define these variables at the command line using the following flag:
      -DCMAKE_C_COMPILER=gcc -DCMAKE_C_COMPILER_LAUNCHER="polyspace-code-profiler;-instrument;-instrum-dir;instrumFolder;--"

    • CMAKE_CXX_COMPILER_LAUNCHER: Set this variable to the full path of the polyspace-code-profiler command. Add appropriate polyspace-code-profiler options, separating the command from options and options from each other using a ; separator.

      For instance, to construct the command:

      polyspace-code-profiler -instrument -instrum-dir instrumFolder -- g++ files
      You can define these variables at the command line using the following flag:
      -DCMAKE_CXX_COMPILER=g++ -DCMAKE_CXX_COMPILER_LAUNCHER="polyspace-code-profiler;-instrument;-instrum-dir;instrumFolder;--"

    • CMAKE_EXE_LINKER_FLAGS: Set this variable to flags required for linking to the precompiled coverage instrumentation library available with Polyspace Test.

      For instance, to link to the library libmwpsprofile_cli_runtime, precompiled using MinGW in Windows, you can define the variable as follows:

      -DCMAKE_EXE_LINKER_FLAGS="-L \"polyspaceroot/polyspace/psprofile/lib/win64/import/mingw64\" -L \"polyspaceroot/polyspace/psprofile/lib/win64\" -l mwpsprofile_cli_runtime"
      Here, polyspaceroot is the path to the Polyspace installation folder, for instance, C:/Program Files/Polyspace/R2026a.

Algorithms

The code coverage calculation algorithm consists of several steps. The code instrumentation step:

  1. Runs the compileCommand or the MSbldCommand.

  2. Extracts source filenames from the executed processes.

  3. Instruments the source files with Polyspace Test macros to collect code profiling data.

  4. Creates the test executable.

After creating the test executable, in the next step, run the test executable. This step collects the code profiling data from your source code.

Once you generate the code profiling database, create an HTML or XML report from the data base.

For the complete workflow, see:

Version History

Introduced in R2023b

See Also

| | | | | | | |

Topics