Constructing the CTC Runtime for the Target

HOTA Files

The HOTA add-on package contains the source code files:

• targdata.c: It contains the runtime logic of Testwell CTC++ at the target and does not need to be changed.
• targcust.c: It may be customized if the standard C system library (e.g. malloc()) is not available at the target.
• targsend.c: It has to be customized for writing out the coverage data. It contains a default implementation using stdio.h to write the coverage data to a local text file at the target.

and the header files targdata.h, ctctypes.h and transfer.h which does not have to be customized.

When the targcust.c and targsend.c files have been checked and adapted as needed, they are compiled to objects with the cross-compiler. Those objects make up the Testwell CTC++ runtime library for the target.

It is also possible to build a static or dynamic library from these files (in a way as the target compilation system and runtime context allows).

Designing the Coverage Data Write-out

The file targsend.c contains the functionctc_send_data() writing the coverage data out. If its default implementation cannot be used straight away, the Testwell CTC++ user is able (and responsible) to modify this function.

The basic structure of ctc_send_data() is:

/* Structure of ctc_send_data() in targsend.c */
#include "targdata.h"
 ...
 void ctc_send_data(void) {
   int ch;
   ...
   ctc_prepare_upload();
   while ((ch = ctc_get_character()) > 0) {
       ... /* write ch to "somewhere" */
   }
   ...
}

The Testwell CTC++ runtime for targets (implemented in targdata.c) encodes the coverage data to a stream of printable ASCII characters. The function ctc_send_data() pulls out the chars one by one and writes them to "somewhere" - to the file system of the target, or directly to the host using any communication method available.

This overview shows the basic possibilities to transfer coverage data from the target to the host:

A (Default Implementation): ctc_send_data() creates the file MON.txt at the local file system of the target and writes the characters there. In one ctc_send_data() call all collected coverage data since program start or a previous call are written out. The file has to be written in append mode. After testing, the file has to be copied to the host machine.

B: If the target can write directly to host disk, this is an even simpler arrangement: The MON.txt file can be written there.

C: In some host-target setups the targets programs can use certain kind of “debug channel”. It is some debug_print() kind of arrangement by which the target program can write messages to the host screen, and these messages can be recorded at the host to a text file. ctc_send_data() can use this way to transfer the coverage data to the host. In ctc_send_data() you just collect the data to small slices, say ~70 chars long. Put prefix "CTCDATA:" at the beginning and write the line (atomic write is assumed!) to the debug channel. At the host the debug log is fed to ctc2dat utility. It extracts the coverage data from the lines that are prefixed by "CTCDATA:" and ignores all other lines.

D: If at the target context there is no printf() kind of outputting possible, but some line communication to the host can be used, you just have to implement what is needed and write the coverage data to the channel. The host side "listener program" then writes the MON.txt file, appending it each time when it gets a complete "write-out burst".

nc -l -p 1234 | ctc2dat -o MON.dat

One specific Testwell CTC++ use is called Kernel Coverage. Imagine it as if your normal Linux kernel had been instrumented by Testwell CTC++ in HOTA style. In such context the coverage data write-out can be arranged in a special way:

The targsend.c’s ctc_send_data() function can be implemented as if it were a text-mode device driver. At the application level ctc2dat program is run. It is made to read this specific device. The char stream, one “write-out burst”, is read. When ctc2dat has got it completely, it writes the coverage data to the datafile.

In the previous A, B, C, D arrangements the initiative to start the write-out act was at the instrumented code side. In this driver approach the initiative is outside of the instrumented code.