Green Hills, GHS, MULTI, 2000, C, C++, ADA, Compiler, Safety, DO-178B Leve A, G-Cover, Coverage, Object Code Analyzer

Safety Critical Products G-Cover Safety Critical Products: G-Cover Object Code Analyzer

Non-intrusive object-level testing

Safety critical standards require that software be thoroughly tested. Simple structural coverage at the source level can be used for low levels of criticiality. Top levels of criticality not only require that software be tested down to the object code level. Further, testing must be performed on the actual software, which means no code instrumentation is allowed. Green Hills Software G-Cover tool automates testing by providing object level coverage analysis and producing coverage reports in a nonintrusive manner. It is a qualified tool for DO-178B Level A testing and can be used for other similar safety standards such as the nuclear power industry’s IEC-880 for example.
Qualified for DO-178B Level A
G-Cover automates the structural coverage analysis of DO-178B Table A-7, Objectives 5, 6, and 7 (statement, decision, and MCDC coverage achievement). Instead of using code instrumentation to obtain coverage, G-Cover uses debugging facilities (breakpoints, single-step, read registers, etc.) as well as the target’s physical debugger interface to monitor the execution of production code modules selected by the user. Besides providing coverage analysis at the object code level, G-Cover offers the following advantages: G-Cover can be used for all source languages (with some restrictions), including assembly. All object code branches and blocks are covered, including those not directly traceable to the source code. This helps users discover object code added by the compiler that was not directly traceable to the source code. The code under test is identical to that in the final product—no instrumentation is added. Instrumentation changes the target object code (especially register usage) and can mask some compiler-induced errors. G-Cover analyzes the object code to determine the location of all conditional branches, calls, jumps, branch targets, jump targets, traps, and exit instructions.With this analysis, G-Cover creates a set of debugging instructions to trap each: subroutine entry and exit entry into each code block execution of both true and false targets for each conditional branch (uses single step debugging feature). The debugging instructions are loaded into a probe connected to the target via a JTAG/BDM, Ethernet, or serial interface and the executable is downloaded to the target. As the executable runs, the debugger uses breakpoints to detect entry into the various blocks and tags each block reached. It also tags the next instruction entered following conditional branches. When the executable completes running, G-cover performs an analysis of tagged blocks and conditional branch targets to determine the code coverage.
Reports and analysis
G-Cover generates a report showing which blocks of the code under test were and were not covered. Users can analyze this report along with the compiler assembly listing (which includes the source level code statements) to determine what source code was not covered. These coverage results help users determine what further action is needed to resolve the lack of coverage: the test is incomplete the requirements are incomplete the code is in error the code is dead the code is deactivated, etc. MCDC coverage analysis relies on boolean operators in the source code being implemented with “short circuit” operations (i.e., conditional branch for each boolean operator) instead of bitwise logical operations, which the Green Hills compilers support. In these cases, each operand has its own conditional branch and G-Cover checks for coverage of the N+1 branches.