Coverage and Profiling for Real-Time Tiny Kernels
Sital Prasad Kedia, Anusree Bhattacharjee, Rajeshwar Kailash and Saurabh Dongre
Memory Solutions Group
Samsung India Software Operations
Email: sital.kedia@samsung.com
Abstract—Real-time tiny kernels run on the embedded devices
with limited resources (especially memory) and usually with no
file system. How theses real-time tiny kernels can be enhanced
to enable coverage and profiling for the applications running
in them using gcov and gprof tool provided by GCC has been
described in this paper. The changes made in gcc-tool-chain in
order to separate the gprof tool (based on version glibc 2.8 and
binutils 2.18.50) so that it can be used for any target architecture
and for any real-time OS without file system has been described
here. Furthermore, when an application is enabled for coverage
or profiling, its memory footprint as well as the execution time
increases significantly. Due to the stringent memory constraint on
embedded devices, it is necessary to keep the memory footprint of
the running applications as small as possible. Hence, in this paper,
a feature called function level coverage and profiling is described,
which can be used to reduce the memory footprint and the
execution time for coverage and profiling enabled applications.
The above mentioned feature is incorporated in GCC (version
4.3) and the changes required in gcc-tool-chain to implement
the feature have been described. Function level coverage and
profiling feature was tested on arm target board with uC/OS-II
RTOS and results show that it can save significant amount of
memory on target board as well as it can reduce the execution
time of the coverage/profiling enabled applications.
I. I NTRODUCTION
A. Motivation
Coverage and profiling tools such as gcov and gprof gives us
some basic performance statistics, which allow us to optimize
our code in an efficient way. Gcov [2] is used to create more
efficient and faster running code and discover untested part of
the program and gprof [3] is used to determine which part of
our code uses greatest amount of the computation time. These
profilers examine the temporal (execution time) and spatial
(code size) [12] efficiency of the program. Since memory
space in embedded devices is of premium value, use of such
coverage and profiling tools are indispensable in development
of applications for embedded system. Many such tools [13]
[14] have been developed for embedded systems. However,
these tools require file system support on the embedded
devices and real-time tiny kernels cannot afford to have the
luxury of having file system with them. Porting of gcov on
embedded target board without file system support has already
been described in [6].In this paper we have described how the
profiling tool gprof was ported to the embedded target board
without file system support.
Moreover, enabling coverage or profiling for an application
increases the memory footprint (approximately 108 bytes/ ba-
sic block on arm target board for coverage) and execution time
of the application significantly which is directly proportional
to the number of functions (in case of profiling) or number of
basic-blocks (in case of coverage) in the code and our target
board may not have sufficient memory to satisfy this additional
memory requirement. Hence we have implemented a feature
called function level coverage and profiling in GCC by which
we can disable coverage/profiling for some functions in a file,
saving the extra memory space required for coverage/profiling
of those functions.
To enhance the tiny kernels with gcov and gprof tools one
has to understand how these tools really works on Linux
environment. On Linux, GCC compiler links these tools to the
application for which code coverage or profiling analysis has
to be done. So for enhancing tiny kernels with these tools, the
tiny kernel and the application has to be compiled and linked
with the help of GCC (cross gcc-tool-chain based on target
architecture)compiler.
The rest of the paper is organized as follows. Section II
discusses the coverage analysis and gcov. An introduction
to profiling and operation of gprof tool on Linux has been
discussed in section III. Porting of gprof to real-time tiny
kernel has been presented in Section IV. Section V presents
function level coverage and profiling. Simulation results are
discussed in Section VI and we conclude in section VII.
II. C OVERAGE ANALYSIS AND GCOV
Code coverage [8] analysis is all about finding the areas of
code not exercised by a set of test cases. It can be used in the
following two ways. First, it measures the quality of the test
cases by finding to what extent our test cases cover our source
code. This allows us to create more test cases to increase
the code coverage. The quantitative measure of code coverage
determines the end product quality; hence coverage analysis is
helpful for improving the end product quality. Second, it can
be used to eliminate dead code from our program that reduces
the code size, which in turn reduces the memory footprint of
the application. Due to the stringent memory requirement of
the embedded devices, coverage analysis is very important in
the context of designing applications for real-time tiny kernels.
Gcov is the code coverage analysis infrastructure provided
with gcc compiler. It can be used to analyze the C, C++ as
well as assembly files [9]. It uses a technique called code
instrumentation [12] to generate coverage information of a
program. Gcov framework consists of the following 3 phases
[6].
1) Compilation Phase
 2) Execution Phase
3) Reporting Phase
When a program is compiled in gcc with
-fprofile-arcs -ftest-coverage options, GCC
inserts counting instruction at the beginning of each basic
block. It also generates graph file (.gcno) [2] for each
compilation unit which contains information to reconstruct
the basic block graph and assign source line numbers to
blocks at the reporting phase. During execution of the
instrumented binary, the counting instructions for each basic
block are executed before execution of the block itself. These
counting instructions simply increment the counter variables
for the corresponding basic block and thus keeping track
of the number of times each basic block in the source file
was executed. At the end of the program execution, these
counter variables are written in a data file (.gcda) [2].
During reporting phase, gcov utility reads both the graph files
and the data files and maps the counter variables in the data
files to the corresponding line number in the source file and
generates a coverage report(.gcov). In real-time tiny OSs,
file system support is not available, so all the coverage data
has to be written into the memory at the end of the execution
phase, later it should be manually transferred to the host PC
for reporting phase. In [6] authors have described a method of
porting the gcov tool for embedded target without file-system
support, which involves major steps like
• Allocating memory for counter variables before the call
to the main function.
• Replacing the standard C library calls like file operations
and dynamic memory allocation.
• Manual call to gcov exit function to write the data into
memory.
III. P ERFORMANCE PROFILING AND G PROF
Software performance analysis, more commonly known as
profiling [11], is an investigation of programs behavior based
on the information collected as the program executes. Profiling
allows us to learn in which part our program spent most of
the execution time, so that these parts can be rewritten to
make the program execution faster. Generally profiling can
be accomplished in two ways, 1.Sampling 2.Instrumentation
[11] [12]. In sampling, the targets program counter is probed
on a regular interval by interrupt generated by the operating
system. On the other hand, instrumentation involves adding
some extra instructions to the target program to collect the
profiling information. Instrumentation typically slows down
the program execution, but it is considered to be more accurate
than sampling.
Gprof is a profiling tool provided with the gcc compiler
which uses both statistical sampling and instrumentation tech-
niques to gather profiling information. For each function, it
records the number of calls to the function and the amount
of time spent there. From gprofs output, we can identify
the functions which consume large fraction of execution time
and try to optimize those functions. Similar to gcov, gprof
framework also consists of the following 3 phases:
1) Compilation Phase: When the program is compiled in
gcc with profiling enabled (-pg option), gcc causes every
function to call the mcount routine as its first operation. The
mcount routine is included in the profiling library, which in-
creases execution count of the current function and updates the
call graph by retrieving the caller identity through the return
address in the stack and the called identity through the value
of program counter. Since this is a very machine-dependent
operation, mcount itself is typically an architecture dependent
short assembly-language stub routine. During linking phase,
depending on the processors architecture gcc links the object
files to the corresponding mcount routine.
2) Execution Phase: Every executable file (.elf) in Linux
has a constructor and a destructor section. Functions in the
constructor and destructor sections are executed before and
after the execution of the main function respectively. For a
profiling enabled application to collect the histogram data, it
is necessary that the memory array for the histogram should
be allocated before the call to main function. To accomplish
this, gcc inserts gmonstartup function as a constructor to the
executable of a profiling enabled application. This function
calls the monstartup function with start of text segment and
end of text segment as arguments. The monstartup function
registers a memory array with the kernel (for storing the
histogram record), along with a scale factor that determines
how the program’s address space maps into the array by
calling the profil() function. The profil() function also sets a
timer interrupt with profile count as the call back function for
the interrupt. The frequency of the interrupt is determined by
the profil frequency function. The profil count function being
called after every equal interval examines the value of the
program counter and increments the corresponding slot of the
histogram array.
After the program execution, writing of the profiling data
is accomplished by a call to mcleanup function (in the
destructor section). The mcleanup function opens gmon.out
file and writes the histogram, call-graph and basic-block count
records to the file.
3) Reporting Phase: During reporting phase, the gprof
utility reads the profile data written into the gmon.out file
in execution phase and generates mainly two types of output
style: namely flat profile and call graph [3]. The flat profile
shows the time spent in each function while the call graph
shows the caller and called information of a function.
IV. P ORTING OF G PROF TO R EAL -T IME T INY K ERNEL
Gprof works on Linux which has support for the features
like file system and dynamic memory allocation. Now if we
want to port it to real time tiny kernels then we have to make
changes in gprof so that it does not use any of the above
described features. Following are the changes that were made
in gprof in order to port it to the real time tiny kernel.
A. Ensure call to monstartup routine before main
As previously discussed, the monstartup function does the
initialization of the memory array to store the histogram
data. Hence before calling main routine of the program the
monstartup routine should be called with the images text
section start and text section end address as arguments. The
text section start and end addresses can be achieved from linker
script.
B. Remove OS and target architecture dependencies
The functions like profil and profil frequency should be
ported not to use any Linux system calls (like setitimer). The
profil frequency function should be ported so as to return the
frequency with which the program’s program counter should
be examined by the profil count function. This frequency
should be chosen very carefully depending on the context
switch time of the target board and the desired accuracy of
the profiling result. If the frequency of profiling is very large,
context switching takes most of the program execution time
and this slows down the program execution significantly. On
the other hand if it is small then the accuracy of the profiling
result will be hampered [3]. As already discussed, the profil
function sets a timer interrupt with profil count as the call
back function. On target board we need to make sure that
the profil count function is being called after every equal
interval determined by the profil frequency function. This can
be accomplished by a call to profil count function from the
Interrupt Service Routine (ISR) after every equal interval
determined by the profil frequency function.
All C standard library dependencies (like file system calls
and dynamic memory allocation) should be replaced to use the
system calls provided by our target OS and file system usage
should be handled by writing data into static buffers.
C. Exit point
At the end of execution an explicit call to mcleanup
function is required to write the data into memory (to the static
buffer allocated for gprof data). The profiling data in memory
should be transferred to the host pc for reporting phase.
V. F UNCTION LEVEL C OVERAGE AND P ROFILING
As already discussed, in case, coverage is enabled for a
particular file, GCC adds counting code for each and every
basic block in the file. Similarly, if profiling is enabled, GCC
adds profiling code for each and every function in the file. So
enabling coverage or profiling for a particular file results in
increase in the text segment size as well as data segment size,
which in turn increases the memory footprint of the resulting
binary for the target machine. But real time tiny kernels
generally lacks in memory space to satisfy the extra memory
requirement imposed by GCC for coverage and profiling. For
the above mentioned reason, we have implemented a feature
called Function level Coverage and Profiling, which allows us
to select or deselect some functions in a file for coverage or
profiling. This feature can be independently implemented into
GCC by some minor changes in the gcc-tool-chain. Though,
GCC implements a feature called file level coverage and
profiling by which we can enable or disable some files for
coverage/profiling in our application, there are situations when
we want to profile only a few functions in a file. Following
are some advantages of this feature:
• We can disable coverage/profiling for some trivial func-
tions in a file which we don’t want to profile and thus
saving the extra memory that would be required for
coverage/profiling of those functions.
• Coverage/profiling of the whole application can be per-
formed in multiple run, enabling a part of the application
for coverage/profiling in one run, in case we are lacking
short of memory in the target board.
• This feature can be useful when we are interested in
obtaining the percentage of coverage (line coverage or
function coverage) only for selected functions in a file.
To implement the aforementioned feature, changes have to
be made in the gcc tool chain itself. Following are the two
major changes required to be made in GCC.
1) Implement a mechanism through which we can specify
GCC, the list of functions that are enabled for cover-
age/profiling.
2) For each function under compilation, GCC should add
the coverage/profiling code to the function, only if it is
enabled for coverage/profiling.
First change can be implemented in several ways. The
conventional way is to implement a new command option
to GCC so that we can specify the list of functions that
are enabled or disabled for coverage/profiling from com-
mand line itself. However, to make things simpler we spec-
ified the list of functions enabled for coverage/profiling in
the source file itself. Some dummy macros like COVER-
AGE ENABLE (function_name) or PROFILE ENABLE
(function_name) were defined. These macros were defined
to NULL and they only served as a place holder for the
function names that are enabled for coverage/profiling. A
separate parser function was implemented in GCC which
opens the current file under compilation (represented by the
global variable input_filename) and searches for the
above specified macros (as keyword) in the file and constructs
a list of functions that are enabled for coverage/profiling. For
each function under compilation, GCC searches the above
specified list for the function name (represented by the global
function current_function_name ) and if the function
name is present in the list then it adds the coverage/profiling
code to the function.
A. Function Level Coverage
As previously discussed, GCC creates two types of files i.e.
graph file (.gcno) and data file (.gcda) for each coverage
enabled file. Graph file contains information to reconstruct
the basic block graph and assign source line numbers to
blocks and is generated when the source file is compiled
with the GCC -ftest-coverage option. Data file contains
arc transition counts and some summary information and is
generated when a program containing object files built with the
GCC -fprofile-arcs option is executed. When a source
file is enabled for coverage, GCC defines counter variable and
adds counting code to each and every basic block in the file.
These counter variables are incremented by the corresponding
counting code during the program execution and are written
into the data file at the end of program execution via a call to
function at_exit via gcov_exit
To implement function level coverage, changes has
to be made in GCC such that both data file and
graph file contain information only for coverage en-
abled functions. For each function in the source file, the
branch_prob function (in profile.c), adds informa-
tion for the particular function to the graph file by a
call to the function coverage_begin_output. In ad-
dition to that, the branch_prob function calls the func-
tion instrument_edges, which instruments all the ba-
Fig. 1. Data Segment size vs. number of coverage enabled functions
sic blocks in the current function. It does so by defining
counter variables and adding counting code (for each ba-
sic block) to the resulting object file. The branch_prob
function should be modified so as to call the functions
coverage_begin_output and instrument_edges,
only for those functions which are enabled for coverage. It can
know whether the current function is enabled for coverage by
searching for the current function name in the list of functions
enabled for coverage.
B. Function Level Profiling
As discussed in section III, for profiling enabled files,
GCC adds profile hooks, which is call to monitoring routine
(mcount) at the beginning of each and every function in that
file. Although inserting a call to mcount routine instruction
doesn’t increase the size of text segment significantly, it Fig. 2. Text Segment size vs. number of coverage enabled functions
introduces significant overhead in terms of time required to
execute the program.
To implement function level profiling, the mcount routine size and binary size. For noting the size of text segment and
should be called only for those functions which are enabled data segment, a separate map file was created by the linker
for profiling. The function expand_function_start (in with Map option.
the file function.c) is responsible for adding profil- Figures 1,2,3 and 4 show the results of memory analysis
ing hooks to each function. It does so only if the flag for coverage enabled applications. Figure 1 compares the size
current_function_profile is set for the current func- of data segment against the number of functions enabled for
tion being compiled. To implement the function level profiling, coverage. As the number of functions enabled for coverage
the current_function_profile flag should be set to
0 for all the functions that are not enabled for profiling
and this has to be done at the prologue of the function
expand_function_start.
VI. RESULTS
We ported the gcov and gprof utilities to arm target board
with UC/OS-II RTOS as operating system. Changes were
made in gcc-tool-chain to implement the function level cov-
erage and profiling feature. We have analyzed the memory
overhead (per function) imposed for coverage and profiling
enabled applications on arm target board with UC/OS-II
RTOS. A C program having 1000 simple functions with each
function having exactly 3 basic blocks was written. Memory
analysis was done by enabling varying number of functions
for coverage and profiling for different runs of the application
and then noting the size of text segment, data segment, object Fig. 3. Object size vs. number of coverage enabled functions
 Fig. 4. Binary size vs. number of coverage enabled functions Fig. 5. Text segment size vs. number of profiling enabled functions

increases, the number of basic block enabled for coverage

increases and consequently size of the data segment increases.
This is due to the fact that GCC defines counter variables for
each basic block and as the number of basic block enabled
for coverage increases, the number of counter variables and
hence the data segment size increases linearly. The increase
in data segment size for 100 functions (= 300 basic blocks) is
approximately equal 2.4 Kb so the corresponding increase per
basic block is 8 bytes. Figure 2 depicts a linear increase in
the text segment size against the number of functions enabled
for coverage. Again this linear increase in text segment size
is due to the fact that GCC adds counting code for each
basic block enabled for coverage. Approximate increase in
text segment size for 100 functions is 25Kb, so increase per Fig. 6. Object size vs. number of profiling enabled functions
basic block is approximately equal to 83.3 bytes. Comparison
of increase in object size and binary size is given in figure
3 and 4 respectively. Increase in object size and binary size age/profiling enabled application increases. In case of cov-
is almost same and is approximately equal to 100 bytes/basic erage, the increase in time of execution is due to execution
block. of extra counting instructions added at the beginning of every
The extra memory space required to execute coverage basic block in the coverage enabled functions and in case of
enabled binary on the target board can be estimated as the profiling, the same is due to call to monitoring routine at the
sum of increase in data segment size and increase in binary prologue of every profiling enabled functions.
size which adds up to 108 bytes/ basic block. In other words,
we can say that 108 bytes of memory space can be saved on
arm target board by disabling a basic blocks for coverage.
Figures 5,6 and 7 show the results of memory analysis for
profiling enabled applications. In figure 5, we observe that the
size of text segment increases with the number of functions.
This increase is due to insertion of call to mcount statement
in the prologue of each function enabled for profiling. A
similar increase in object size and binary size can be observed
in figure 6 and 7. The data segment size was found to be
independent of the number of functions enabled for profiling.
It should be noted that in case of profiling, the increase in text
segment, object size and binary size is significantly less then
the corresponding increase in case of coverage.
Time analysis for coverage and profiling is given in figures
8 and 9. As the number of functions enabled for cover-
age/profiling increases the time of execution of the cover- Fig. 7. Binary size vs. number of profiling enabled functions
 [5] S.Graham, P.Kessler, M.McKusick, “gprof:A Call Graph Execution
Profiler”, Proceedings of SIGPLAN’ 82 Symposium on compiler
Construction, SIGPLAN Notices, Vol. 17, No 6, pp. 120-126, June
1982.
[6] Holger Blasum, Frank Gorgen, Jurgen Urban “Gcov on an embedded
system”, GCC for Research in Embedded and Parallel Systems,
Brasvo 16 Sept 2007.
[7] Dominic A. Varley “Practical Experience of the limitations of Gprof”,
Software Practice and Experience 23, 461- 463.
[8] S Cornett, Code coverage analysis, Accessed February, 2010. [Online].
Available: http://www.bullseye.com/coverage.html.
[9] X Fei, L Luo 2004, Using the GNU tools to measure assembly
program coverage (Liyong GNU gongju shixian huibian chengxu fugai
ceshi), Journal of Computer Applications (Jisuanji Yingyong, ISSN
1001-9081), Vol 24 No. 12 pp. 95-98.
[10] Q Yang, JJ Li, D Weiss, 2006,“A survey of coverage based testing
tools”, in: Proceedings of the 2006 International Workshop on
Automation, AST’ 06 Shanghai 2006, pp. 99-103.
Fig. 8. Execution time vs. number of coverage enabled functions [11] Profiling (Wikipedia), Accessed February, 2010. [Online]. Available:
http://en.wikipedia.org/wiki/Profiling (computer programming)
[12] Ramesh V Peri, Sanjay Jinturkar and Lincoln Fajardo 1999. A novel
technique for profiling programs in embedded systems. In ACM
Workshop on Feedback-Directed and Dynamic Optimization
(FDDO-2).
[13] OProfile - A System Profiler for Linux, Accessed February, 2010.
[Online]. Available:http://oprofile.sourceforge.net/news/
[14] Valgrind, Accessed February, 2010. [Online].
Available:http://valgrind.org/

Fig. 9. Execution time vs. number of profiling enabled functions

VII. C ONCLUSION
We have ported the gprof tool provided by GCC to real-time
OSs without file system support. Also, we have implemented
a feature called function level coverage and profiling in GCC.
We have described in details, the changes made in gcc-tool-
chain to implement the above feature. The feature was tested
for arm target board using UC/OS II RTOS and results show
that our feature can save significant amount of memory on
target board as well as it can reduce the execution time of the
coverage/profiling enabled applications.

R EFERENCES
[1] GNU GCC Compiler Collection, Accessed February, 2010. [Online].
Available: http://gcc.gnu.org/
[2] Free Software Foundation, gcov - a Test Coverage Program in: Using
the GNU Compiler Collection (GCC), Accessed February, 2010.
[Online] Available:
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/Gcov.html
[3] GNU gprof in: Documentation for binutils 2.20, Accessed February,
2010. [Online]. Available:
http://sourceware.org/binutils/docs-2.20/gprof/index.html
[4] Implementation of profiling in GNU gprof in: Documentation for
binutils 2.20, Accessed February, 2010. [Online]. Available:
http://sourceware.org/binutils/docs/gprof/Implementation.html#
Implementation