CTC++ supports Symbian OS C/C++ code test coverage
measuring and dynamic analysis in the following contexts:
- On the EPOC emulator (Symbian
OS, v9.1 and later) on Windows:
- With Nokia Codewarrior C/C++ Compiler for Windows/x86
(mwccsym2)
- Builds with CTC++ can be done
- In command-line mode (abld and sbs)
- Call for latest status of Carbide.c++ IDE integration
- On the target device,
user-mode code (Symbian OS, v9.1 and later, EKA2 kernel):
- Development is done on Windows host
- The code under test at the target is normal user-mode code
(EXEs and DLLs)
- The supported cross-compilers are
- RVCT 2.2, 3.1, 4.0 (armcc)
- GCCE (arm-none-symbianelf-g++)
- Builds with CTC++ can be done
- In command-line mode (abld and sbs)
- Call for latest status of Carbide.c++ IDE
integration
The EPOC emulator support
is included already in the basic CTC++/Windows delivery
package.
The Symbian target device support is a separate
sales package, called "CTC++ for Symbian Target Devices
add-on". For using it the basic CTC++/Windows is also
needed.
The usage of these variants is quite "out of the box"
and very easy. They are described below:
Nokia Codewarrior C/C++ Compiler for Windows/x86
(mwccsym2) is supported. The used SDK needs to be compliant to the
used compiler.
If you normally build your code for the
emulator for example as follows:
Previously, since November 2003 when we first
released this package, it supported the Symbian OS level
up to v8 (EKA1 kernel). Our support for that level has been
discontinued. In April 2007 we released an upgrade to this add-on
package supporting Symbian OS v9 onwards (EKA2 kernel). The text
below talks of the Symbian OS v9 level version of this add-on
package.
Some characteristics of this CTC++ add-on are:
- Usage (running the instrumented programs) is possible in
normal "street phones" (having Symbian OS v9.x)
- The code under test is user-mode code
- No modifications to your original source files or project
definition files (.mmp) are needed for the sake of using with
CTC++
- Your instrumented programs and the CTC++ program components
can be installed to the device's primary memory or to its
additional memory (memory card)
- If it is possible for you to make "ROM-builds", the
instrumented code and the CTC++ programs can reside also in ROM
- The CTC++ overhead to the execution speed and memory
consumption is very reasonable
Again, the usage is very
simple. If you normally build as follows (examples of abld and
sbs toolchains):
abld build armv5 urel
sbs -c armv5_urel
you
just change the building command to the following form:
ctcwrap -i m abld build armv5 urel
ctcwrap -i m sbs -c armv5_urel
According
to the makefile rules (implied by the original abld or sbs command)
the source files are instrumented and compiled with the armcc
compiler and the instrumented target program (normally an .exe or a
.dll) is linked.
This CTC++ add-on package contains 3
ready-compiled CTC++ components: a CTC++ run-time support layer on
the target (a .dll) and two auxiliary programs (one
for graphical menu usage, the other for text shell command-line
usage) by which the coverage data is managed on the target
device.
The user's instrumented program components and the
CTC++ program components are worked up to installation packages (SIS
files), all signed with the user's own developer keys (DevCerts),
and installed onto the phone.
Test runs on the phone are done
in a normal manner. Several (instrumented and other) test programs
can be run in sequence or in parallel, as the test plan may need.
All the time the coverage data of the instrumented programs is
collected to the memory of the device. At some point of time
the CTC++ control program is started and with a few keystrokes the
coverage data is written from the main memory to a file on the
device. Also the RDebug channel can be used. The coverage data file
is moved to Windows where it is imported to a CTC++ datafile.
The reports (text and HTML) are then obtained on Windows with the
normal CTC++ tool chain using the
ctcpost and
ctc2html utilities.
All
CTC++ features can be used on the target. The primary use may be
measuring code coverage, but function execution timing and
call tracing features can be used, too.