Build configuration settings

Use the build configuration settings to change how the project is built in HCL OneTest™ Embedded for Eclipse IDE.

To access the build settings, right-click the project and select Properties > C Build > Settings > Build Settings.

General

Selective instrumentation

Build options: Specifies the runtime analysis options for the selected resource. This is also where you enable the runtime analysis tools. See Enable runtime analysis tools.
Instrument inline methods: Extends instrumentation to inline methods.
Instrument included methods or functions: Extends instrumentation to included methods or functions.
Excluded files: Specifies a list of source files that are parsed during the run, but are not instrumented. Click the ... button and use the Add and Remove buttons to select the files to be excluded.
Excluded directories: Specifies a list of directories containing source files that are parsed during the run, but are not instrumented. Click the ... button and use the Add and Remove buttons to select the directories to be excluded.
Instrumentor hides all warnings: Set this option to Yes to hide instrumentation warnings.

Snapshot

In some case, such as with applications that never terminate or when working with timing or memory-sensitive targets, you might need to dump traces at specifics points in your code. See Generating SCI Dumps for more information.

On function entry: Allows you to specify a list of function names, from your source code, that will dump traces at the beginning of the function. Click ... and use Add and Remove to create a list of function names.
On function return: Allows you to specify a list of function names, from your source code, that will dump traces at the end of the function. Click ... and use Add and Remove to create a list of function names.
On function call: Allows you to specify a list of function names, from your source code, that will dump traces before the function is called. Click ... and use Add and Remove to create a list of function names.

Static file storage

Depending on the runtime analysis feature, the product generates .tsf or .fdc temporary static data files during source code instrumentation of the application under analysis.

Code coverage static file storage (.fdc)

These settings apply to code coverage .fdc static trace files:

Build Directory: Select this option to use the current directory for all generated files.
Other Directory: Select this option to define a specific directory.
Source Directory: Select this option to use the same directory as the source under analysis.
Use Single Temporary File (.fdc): By default, code coverage produces one .fdc file for each instrumented source file. Select this option to use a single .fdc file for all instrumented source files, and specify its location.

FDC directory or name

If the Use single temporary file (.fdc) option is selected in the previous setting, specify a location for the .fdc file.

Memory profiling, performance profiling, runtime tracing static file storage (.tsf)

This setting applies to memory profiling, performance profiling and runtime tracing .tsf static trace files.

Build directory: Select this option to use the current directory for all generated files.
Other directory: Select this option to define a specific directory.
Source directory: Select this option to use the same directory as the source under analysis.
Use single temporary file (.tsf): By default, memory profiling, performance profiling and runtime tracing produce one .tsf file for each instrumented source file. Select this option to use a single .tsf file for all instrumented source files, and specify its location.

TSF directory or name

If the Use single temporary file (.tsf) option is selected in the previous setting, specify a location for the .tsf file.

Advanced options

Identification header: Select this option to add an identification header to files generated by the instrumentation. The header includes the command line used to generate the file, the version of the product, the date and operating system information.
Application includes system files: By default, unused methods within a template are ignored by the instrumentation. Set this option to Yes to analyze and instrument all template methods, even if they are not used.
Internal data allocation: Set this option to Yes if the application includes system files such as windows.h in Windows™ or pthread.h in UNIX™.
Full template instrumentation: Select either Static declaration or Dynamic allocation as the memory allocation method for storing intermediate variables in the instrumented source code.
Check internal data before use: This setting allows you to add command line options for the instrumentation. Normally, this line should be left blank.
Use alternate checksum: Select Yes to calculate a more unambiguous checksum for .fdc and .tsf files. Select No to remain compatible with existing .fdc and .tsf files. Before using this option, you must delete existing .fdc and .tsf files, which will be recreated with the new checksum. File keys are not changed by this option.
Additional instrumentor options: Set this option to Yes if you are experiencing crashes of the application when runtime analysis features are engaged. This option improves compatibility but increases memory usage.
Generate TPM files: Set this option to Yes if you want to generate metrics for the test process monitor.

Code Coverage

Instrumentation control

You can use the coverage type settings to declare various types of coverage. See Coverage levels for more information about these settings.

Coverage level functions

Select between function Entries, With exits, or None.

Coverage level calls

Select Yes or No to toggle call code coverage.

Coverage level blocks

Select the desired block code coverage type. You can combine, enable, or disable any of these coverage types before running the application node. All coverage types selected for instrumentation can be filtered out in the coverage viewer.

Exclude for loops

Select Yes to exclude for loops from instrumentation. Only while and do loops are instrumented.

Coverage level conditions

Selects the condition level of code coverage to be included in the report:

None: The coverage report ignores conditions.
Basic: Only basic conditions are included in the coverage report.
Modified (MC/DC): Only modified conditions are included in the coverage section of the test report.
Modified and Multiple: Both modified and multiple conditions are included in the coverage report.
Forced Modified (MC/DC): The report includes modified conditions where all operators are replaced with bitwise operators.
Forced Modified and Multiple: The report includes modified and multiple conditions where all operators are replaced with bitwise operators.

Condition in expressions

Select Yes to consider relational operators in an expression (for example: y = ( a>0 ) ) as conditions.

Bitwise as logical

Select Yes to instrument bitwise operators as logical when both operands are booleans.

Ternary coverage

When this option is selected, code coverage reports ternary expressions as statement blocks.

Information mode

This setting specifies the information modes to be used by code coverage.

Default (Optimized for Code Size and Speed): This setting uses one byte per branch to indicate branch coverage.
Compact (Optimized for Memory): This setting uses one bit per branch. This method saves target memory but uses more CPU time.
Report Hit Count: This adds information about the number of times each branch was executed. This method uses one integer per branch.

Excluded function calls

Specifies a list of functions to be excluded from the call coverage instrumentation type, such as printf or fopen. Use the Add, Remove buttons specify the functions to be excluded.

Not returning functions

Type the identifiers (not signatures) of the functions that do not return (functions that execute a longjmp or exit).

Advanced options

Trace file name (.tio): this allows you to specify a path and filename for the .tio dynamic coverage trace file.
Key ignore source file path: Identifies source files based only on the filename instead of the complete path. Use this option to consolidate test results when a same file can be located in different paths. This can be useful in some multi-user environments that use source control. If you use this option, make sure that the source file names used by your application are unique.
User comment: This adds a comment to the code coverage report. This can be useful for identifying reports produced under different configurations. To view the comment, click the a magnifying glass symbol that is displayed at the top of your source code in the coverage viewer.
Report summary: Select Yes to add the coverage summary to the summary text file of the selected node.
On-the-fly frequency dump: Specify the function call number after which the coverage results are updated dynamically during execution. 0 means no update during execution.

Memory Profiling

Instrumentation control

You can specify the type of memory errors and warnings that you want to detect. See Memory profiling errors and Memory profiling warnings for more information about these settings.

Detect File in Use (FIU): When the application exits, this option reports any files left open.
Detect Memory in use (MIU): When the application exits, this option reports allocated memory that is still referenced.
Free Invalid Memory (FIM): This option activates the detection of invalid free memory instructions.
Detect Signal (SIG): This option indicates the signal number received by the application forcing it to exit.
Detect Freeing Freed Memory (FFM) and Detect Free Memory Write (FMWL): Select Yes to activate detection of these errors.
Free queue length (blocks): Specifies the number of memory blocks that are kept free.
Free queue size (bytes): Specifies the total buffer size for free queue blocks.
Largest free queue block size (bytes): Specifies the size of the largest block to be kept in the free queue.
Detect Array Bounds Write (ABWL): Select Yes to activate detection of ABWL errors.
Red zone length (bytes): Specifies the number of bytes added by Memory Profiling around the memory range for bounds detection.
Number of functions in call stack: Specifies the maximum number of functions reported from the end of the CPU call stack. The default value is 6.
Only show memory leaks with call stack: Select this option to only record memory leaks that are associated with a call stack. Memory allocations that occurred before the application started do not have a call stack and are not included in the Memory Profiling report.
Line number link: Select Statement to link the line number in the report to the corresponding allocation or free statement in the function. Select Function to link only to the function entry and to improve performance.
Only show new memory leaks in each dump: In multi-dump report, Memory leaks (MLK) and potential leaks (MPK) are only reported once.

Advanced options

Trace File Name (.tpf)

This setting allows you to specify a filename for the generated .tpf trace file.

Exclude block tracking before init

Disables memory profiling for any memory blocks allocated before the first execution of instrumented code. Use this option to prevent crashes when the system uses memory allocations that cannot be tracked.

Excluded global variables

Specifies a list of global variables that are not to be inspected for memory leaks. This option can be useful to save time and instrumentation overhead on trusted code. Use the Add and Remove buttons to add and remove global variables.

Exclude variables from directories

Specifies a list of directories from which any variables found in files are not to be inspected for memory leaks.

Break on error

Use this option to break the execution when an error is encountered. The break point must be set to priv_check_failed in debug mode.

ABWL and FMWL check frequency

Use this to check for ABWL and FMWL errors:

Each time the memory is dumped (by default).
Each time a manual check macro is encountered in the code.
Each function return.

These checks can be performed either on all memory blocks or only a selection of memory blocks. See Checking for ABWL and FMWL errors for more information.

Preserve block content

Set this setting to Yes to preserve the content of memory blocks freed by the application. Use this setting to avoid application crashes when memory profiling is engaged. When this setting is enable, reads to freed blocks of memory are no longer detected.

Application Profiling

Stack size

You can configure the parameters to calculate the worst stack size.

Trace file name (.tzf): This allows you to specify a path and filename for the .tzf dynamic stack trace file.
Measure Max Stack Used: This allows you to enable the Worst Stack Size feature. The default value is yes.

Report template: You can set your own report template. The default template id ccreport.template.

Debug Reports

You can specify the type errors and warnings that you want to detect.

Display path using biggest stack: Displays the called stack when the biggest stack size is detected during the execution. The selected number is the displayed called stack in the report.

Detect File In Use (FIU): When the application exits, this option reports any open files.

Detect Signal (SIG): This option indicates the signal number received by the application that caused to exit.

Performance Profiling

Trace file name (.tqf): This box allows you to specify a filename for the generated .tqf trace file for performance profiling.
Compute F max and F+D max time: Indicate whether you want the maximum execution time for each function and descendants to be calculated, or not, or if it must be calculated with the Worst Case Execution Time.

Coupling

Control Coupling: You can specify parameter dedicated to the Control Coupling coverage.
Trace File name (.tgf): Set the name of the trace file dedicated to the Control Coupling. It is the default name of the test with the extension .tgf.
Exclude libraries: Include or exclude the Control Couplings ending with a function call that is not part of the application (this option set the option -noccext of the report generator if it is set to yes).
Report template: You can change the template of the report generator. By default the template is ccreport.template.

Runtime Tracing

Instrumentation control

Runtime Tracing file name (.tdf): This allows you to force a filename and path for the dynamic .tdf file. By default, the .tdf carries the name of the application node.
Show data classes: When this option is disabled, structures or classes that do not contain methods are excluded from instrumentation. Disable this option to reduce instrumentation overhead.

Trace control

Split trace file: When you use several runtime analysis tools together, the executable produces a multiplexed trace file, containing the output data for each tool. Use this option to split the generated atlout.spt output trace file into multiple files.
Maximum size (Kbytes): This specifies the maximum size for a split .tdf file. When this size is reached, a new split .tdf file is created.
File name prefix:: By default, split files are named as att_<number>.tdf, where <number> is a 4-digit sequence number. This setting allows you to replace the att_ prefix with the prefix of your choice.
Automatic loop detection: Loop detection simplifies UML sequence diagrams by summarizing repeating traces into a loop symbol. Loops are an extension to the UML sequence diagram standard and are not supported by UML.
Additional options: This setting allows you to add command line options. Normally, this line should be left blank.
Display maximum call level: When selected, the target deployment port records the highest level attained by the call stack during the trace. This information is displayed at the end of the UML sequence diagram in the runtime tracing viewer as Maximum calling level reached.

Runtime options

Disable on-the-fly mode

When selected, this setting stops on-the-fly updating of the dynamic .tdf file. This option is primarily for target deployment ports that use printf output.

Runtime tracing buffer and Partial Runtime Tracing flush

See Advanced runtime tracing for more information about these settings.

Maximum buffer size (events)

The maximum number of events recorded in the buffer before it is flushed.

User signal action

Specify an action to be performed when a user signal is detected:

No action: nothing.
Flush call stack: the call stack is flushed to the trace file.
Runtime tracing on/off: toggles the runtime tracing feature on or off.

Record and display time stamp

This setting adds timestamp information to each element in the UML sequence diagram generated by runtime tracing.

Record and display heap size

This setting enables the heap size bar in the UML sequence diagram generated by runtime tracing.

Record and display thread info

This setting enables the Thread Bar in the UML sequence diagram generated by runtime tracing.

Static Metrics

One level metrics: By default, .met static metric files are produced for source files as well as all dependency files that are found when parsing the source code. Set to Yes to restrict the calculation of static metrics only to the source files displayed in the navigator.
Analyzed directories: This setting allows you to restrict the generation of .met metric files only to files which are located in the specified directories.
Generate metrics in source directories: By default, all .met files are generated in the project directory, and use the same name as the source file. Select Yes on this setting to compute metrics for source files that have the same name but are located in different directories. In this case, each .met is generated in the source directory of each file.
Additional options: Use this setting to specify extra command line options. In most cases, this should be empty.

Code Review

Rule configuration: This setting specifies the file containing the rules for the code review tool. Click Browse ... to select another rule configuration file. Click the Edit button to edit the rule configuration or to create a new rule configuration. See Configuring code review rules for more information.
Additional included system directories: This setting specifies system include directories that are to be ignored during the code review.
Review included system files: Select Yes to extend code review to system files that are #included in the source files.
Naming script file: This setting allows you to specify a perl script that can check your own naming rules.
Include files: Specify a list of files to preinclude. This is similar to the -include=<files> option in gcc.
Display errors/warnings: Specify the maximum number of errors and warnings that you want to display in the report. By default, All errors and warnings are displayed.