Support Overview

For information about supported Green Hills compilers, see Compilers.

Green Hills INTEGRITY project integration is provided by BDF creation/import - see Importing INTEGRITY Projects for Unit Testing or Application Monitoring.

  • All original project options will be captured
  • Direct importing of .gpj projects is only supported for Green Hills MULTI projects (non-INTEGRITY)

C++test can test Dynamic Download INTEGRITY Application Projects that are loaded onto an INTEGRITY kernel (specified by the user). The chosen virtual address space (VAS) to be tested can be run with unit testing or application monitoring. C++test supports automated testing of VAS projects in isolation, therefore some manual modifications to the integrate (.int) file may be necessary if the original project has many virtual address spaces and if those virtual address spaces interact with each other.

C++test enables testing of Green Hills MULTI projects for INTEGRITY applications by supporting the following C/C++ compilers:

  • ccintppc
  • cxintppc

The following components are provided to facilitate testing Green Hills MULTI projects:

  • Run GHS INTEGRITY Tests test configuration for launching unit testing
  • Run GHS INTEGRITY Application with Mem Monitoring test configuration for application monitoring

The following properties are available in Green Hills INTEGRITY test configurations:

  • Debug Server Name: Simulator that will be used to run the test; set to isimppc by default
  • Debug Host Name: Name of host; set to localhost by default
  • Debug Connection Port: - Port number; set to 2220 by default
  • INTEGRITY Kernel: Absolute path to the desired INTEGRITY kernel; set to C:\ghs\int1104\bin\sim800\kernel  by default
  • MULTI board setup script (.mbs): Board specific setup script; no default value

Known Limitations

  • AltiVec extensions are not supported.
  • SPE extensions are not supported.
  • The built-in test configurations assume that you are testing on the isimppc simulator via an rtserv2 connection. Other methods may require customization of the test configuration.
  • C++test does not support multitasking executed via the INTEGRITY API, so it is recommended that calls to such API functionality be stubbed out.
  • Multitasking using the Posix API is supported. See Testing Multi-Threaded Applications, for more details.
  • All unit tests (regardless of which task the tested functions belong to) will be run in a single task. Other tasks should be disabled or else they may interfere with test and coverage results.
  • The following non-standard keywords are not supported
    • __interrupt
    • __packed
    • __bytereversed
    • __bigendian
    • __littleendian
    • __typeof__
    • __linkonce

Requirements

  • Compiler must be on the PATH if the full path isn't specified in the C++test project build options.
  • Simulator (isimppc) must be on the PATH, or specify full path to simulator in the "Debug Server Name" property in the test configuration
  • Debugger (multi) must be on the PATH.

Importing INTEGRITY Projects for Unit Testing or Application Monitoring

  1. Prepare your tested project:
    1. Create (or use an existing) Dynamic Download module. The number of Virtual Address Spaces (VAS) decides if later manual adjustment of the (.int) integration config script is required.
    2. Choose one VAS for testing (for C++test, a single VAS is an atomic application).
    3. Right click the top level .gpj project and choose Edit.
    4. Add :binDir=bin as one of the flags to the project. This argument will ensure that your original project artifacts will not interfere with C++test's automation. C++test runs commands with your project directory as the working directory, so build artifacts that are left there can cause unwanted results when building test executables.
    5. Inside MULTI IDE, double click the .int file to bring up the Integrate GUI.
    6. Double click Task Initial to bring up the Task Options editor.
    7. Select the Start Automatically option to allow for C++test to automatically load and start the tested module on the kernel.
    8. Adjust the "Stack Size" for active/tested task. The C++test runtime will add approximately 8 kilobytes of overhead to a tested VAS, so it's recommended you increase your stack size by 0x2000.
    9. If your project has more than one VAS, create a copy of the original integration config script (.int) and remove all other VAS descriptions from it.
  2. Generate Build Data File (BDF) by executing one of the following commands:

    1. For gpj projects:

      cpptesttrace --cpptesttraceProjectName=<VAS_name>
--cpptesttraceOutputFile="<dir>\vas.bdf"
gbuild -all -top <top_prj_name>.gpj <VAS_name>.gpj

    2. For Make projects:

      cpptesttrace --cpptesttraceProjectName=<VAS_name>
--cpptesttraceOutputFile="<dir>\vas.bdf" make <target_for_chosen_VAS>
  3. Import project to C++test:
    1. In C++test, choose File> New> Project.
    2. Choose C++test> Create project from a build data file and click Next.
    3. Provide the path to to the build data file you generated in part step 2.
    4. Verify that the compiler settings were set correctly and click Next.
    5. Review your project structure and click Finish.
  4. Force integration during VAS linking to prepare the project for testing:
    1. Right-click the project node and choose Properties.
    2. Choose Parasoft> C++test> Build Settings
    3. Append -lhostio and -intfile=<path_to_integrate_file> to the Linker options field in the Options section. C++test requires linking with hostio libraries to use fopen() for writing unit test and coverage data to logs. intfile file is the single-VAS .int file for your INTEGRITY application; it forces the integration step to occur after the linking step is complete.
  5. Select the sources you want to test and choose Parasoft> Test Using> Builtin> Unit Testing> Generate Unit Tests
  6. Ensure the tested functions do not call the Exit() function; if the function is called, make sure that it’s stubbed out. Direct calls to this function will prematurely cause the test executable to its end execution. See Additional Notes, for more details.
  7. If it is not added automatically, insert the following statement into auto-generated stubs:
    #include "INTEGRITY.h. When using auto-generated stubs, the INTEGRITY.h header file is usually required.
  8. Parasoft> Test Using> Builtin> Embedded Systems> Green Hills Software> Run GHS INTEGRITY Tests.

Additional Notes

Disabling grun

By default, the kernel specified in the test configuration properties is started using grun, which is a command used for running debug servers. The grun command is executed with a default timeout of 180 seconds. This stops the kernel in a predictable manner for cases in which the test execution results in erroneous behavior. If you find that you need longer than this 180 seconds for test execution, then you can modify the test execution flow by changing the value attribute for the dbserv_timeout (<SetProperty key="dbserv_timeout" value="180" />) property or by disabling grun.

To disable grun uncomment the following line located inside the test execution flow editor to run the specified kernel using the debug server directly:

  • <!--SetProperty key="kernel_cmd" value="${cpptestproperty:dbserv} &quot;${cpptestproperty:kernel}&quot;" /→

Comment the following line located inside the test execution flow editor to disable grun for kernal execution.

  • <SetProperty key="kernel_cmd" value="grun
${cpptestproperty:dbserv_timeout_opt} ${cpptestproperty:script_opt}
${cpptestproperty:dbserv} -- &quot;${cpptestproperty:kernel}&quot;" />

Regardless of the method chosen for running the kernel, the test execution flow will still attempt to kill any kernel process that maybe running when the test execution is completed.

File Synchronization

In order for the test execution flow to know that a test execution is finished running, a file synchronization step is employed, which can be found toward the bottom of the test execution flow:

<FileSynchronizeStep
   fileSync="${cpptest:testware_loc}/cpptest_results.tlog" 
   fileInactiveTimeout="10000"
/>

This step tracks the timestamp of the test log file. The test log file is updated with information about every test as they are executed. C++test stops the execution if it detects that the log file has been inactive for 10000 milliseconds. If you expect periods of inactivity in your unit tests that might exceed 10 seconds, you should increase the value of the fileInactiveTimeout attribute to the desired timeout value. For more information on the FileSynchronizeStep flow step and other information about test flow execution, see Test Flow Descriptions and Examples.

Increasing Time-to-timeout

The file synchronization method may not be sufficient for proper test execution flow when running application monitoring using the Run GHS INTEGRITY Application with Mem Monitoring test configuration. If your application contains few reportable memory violations, the results file may be updated to infrequently, which may lead to an unwanted timeout.

 In addition to increasing the time-to-timeout, you can use an alternative functionality of the FileSynchronizeStep that forces C++test to wait for the generation of the synchronization file to signal the end of application execution:

<FileSynchronizeStep
   fileSync="<path/to/synchronization/file.txt>"
   timeout="30000"
/>

This synchronization file can either be created manually from inside your application's code, or you can provide an implementation of the CppTest_Finalize function to manually write a file the FileSynchronizeStep will wait for. The CppTest_Finalize function is automatically called as one of the final steps of application execution.

After creating the synchronization file, you can increase the timeout to a value that is sufficient for the duration of your application's running time. For more information about custom initialization and finalization, see Initialization and Finalization.

Preventing Premature Text Execution Completion

Calls to Exit() may need to stubbed out in order to prevent premature completion of test execution, if such calls are used within tested functions. If necessary, you can still call Exit() by implementing the CppTest_Finalize function, which is automatically called as one of the final steps of application execution. For more information about custom initialization and finalization, see Initialization and Finalization.

Automatic Test Execution Reruns

Many C++test test configurations use a mechanism that enables automatic rerunning of test executables after unexpected behavior in an individual test case causes the test executable to crash or abort. This mechanism will rerun the test executable beginning with the next unrun unit test. However, due to limitations in the Green Hills framework for INTEGRITY applications, this mechanism is unavailable when testing INTEGRITY applications. If a unit test causes a premature end to test execution, unit testing will end and results collected up to that point will be available.

Testing Multiple Virtual Address Spaces

While C++test works best when testing a single VAS in isolation, it may be the case where the tested VAS requires interaction with another VAS in the same INTEGRITY application. In this case, some manual customization to the workflow will be necessary. Consider the following :

  • Additional VASs must be built prior to integrating with C++test. See step 1 in Importing INTEGRITY Projects for Unit Testing or Application Monitoring.
  • Because C++test runs the integrate command from the location of the project, the build artifacts for other virtual address spaces would need to be located in the project directory. An alternative would be to place these build artifacts inside the C++test test executable location itself.
  • Running auto-generated tests for functions that require interactions with other virtual address spaces may lead to unpredictable behavior and results. Care should be taken when attempting to test a single virtual address space in conjunction with other virtual address spaces.

C++test Runtime Finalization when using Shared Libraries

The C++test runtime relies on calls to destructors of static objects for some necessary finalization steps during test execution and application monitoring. Due to a current limitation in the Green Hills MULTI v6.1.x C/C++ compiler v2013.1.x for INTEGRITY on PowerPC, destructors for static objects will not be called if the -non_shared  flag is not used in your project. If you are not using the -non_shared compiler flag, you will need to manually insert a call to the CppTest_FinalizeRuntime() function at the end of your application's main() function. This will allow C++test to do all necessary finalization steps. For additional information about how to use the CppTest_FinalizeRuntime() function, see Initialization and Finalization.

  • No labels

Need assistance? Visit our support page