Software profiling in embedded systems with O-profile
What is o-profile?
See the description below extracted from http://oprofile.sourceforge.net/, o-profile official website
OProfile is a system-wide profiler for Linux systems, capable of profiling all running code at low overhead. OProfile is released under the GNU GPL.
It consists of a kernel driver and a daemon for collecting sample data, and several post-profiling tools for turning data into information.
OProfile leverages the hardware performance counters of the CPU to enable profiling of a wide variety of interesting statistics, which can also be used for basic time-spent profiling. All code is profiled: hardware and software interrupt handlers, kernel modules, the kernel, shared libraries, and applications.
OProfile is currently in alpha status; however it has proven stable over a large number of differing configurations; it is being used on machines ranging from laptops to 16-way NUMA-Q boxes. As always, there is no warranty.
Why don’t we use gprof?
For embedded system , we do not use gprof (the GNU profiler) because it is not supported by uClibc. The main reason for this is explained below:
uClibc no longer supports ‘gcc -fprofile-arcs -pg’ style profiling, which causes your application to generate a ‘gmon.out’ file that can then be analyzed by ‘gprof’. Not only does this require explicit extra support in uClibc, it requires that you rebuild everything with profiling support. There is both a size and performance penalty to profiling your applications this way, as well as Heisenberg effects, where the act of measuring changes what is measured.
Preparing your system for o-profile
Your kernel must support o-profile, for this you have to reconfigure it with o-profile enabled as a module.
We’ll use EP9307 linux 2.6 for example in this blog entry.
For EP9307 target, we use make linuxconfig in edb9307 to enable O-PROFILE.
O-profile uses a script to control the profiling called opcontrol.
This script requires bash 2 or superior, so we must cross-compile bash for the platform under test, if it is not already present. It can be downloaded at http://ftp.gnu.org/gnu/bash/.
This script also use a fair amount a shell command (dirname, awk, which, cut etc..) that may have been disabled in busybox, if you see error when running opcontrol, you have to check the command missing and enable them in busybox. For Ep9307 , make busyboxconfig in edb9307 directory can be used to change the settings.
O-profile must be cross-compiled for the platform under test.
It requires the following libraries:
libintl, libbdf, libliberty (part of binutils)
First you need to compile the binutils (preferrably the same used by your cross compiler) as follows:
./configure –target=arm-linux –host-linux –build=i686 –without-gettext –without-intl –prefix=$SRCBLB/libs
You also need to compile gettext (It can be download from one of GNU servers) to be able to compile binutils (even though this was disabled)
To compile libpopt: (Download popt)
./configure –target=arm-linux –host=arm-linux –prefix-$SRCBLD/libs/
To compile oprofile:
./configure –target=arm-linux –host=arm-linux –without-x –with-kernel-support –with-extra-libs=$SRCBLD/libs/lib –with-extra-includes=$SRCBLD/libs/include –prefix=$SRCBLD/tools/oprofile-0.9.1
Finally you have to copy the following files to their relevant directories within the ramdisk.
Enabling profiling in your applications
The good thing here is that contrary to gprof, there is nothing to do to enable o-profile in your application. Although you’d better compile it using debug information (CFLAGS += -g).
First type bash to start the bash shell which is necessary to use opcontrol script.
Getting the profiling data
Initialize oprofile: opcontrol –no-vmlinux
start your application : e.g. /usr/app/app_dbg
Start oprofile: opcontrol –start
wait a few seconds to get profiling data
Stop oprofile: opcontrol –shutdown
Analyzing the results
Opreport is used to display the profiling result, a list of common commands can be found below:
See example of simple report
See example of “long” report
Report with callgraph, you can see what functions are calling other functions in the output:
See example of callgraph report
Report showing source file and line for each symbol:
opreport /usr/app/app_dbg –debug-info –symbols
See example of report showing source code mixed with profiling information
See example of detailed report
The profiling was performed while playing a MPEG-4 video with mplayer on EP9307.
For further information please see: http://oprofile.sourceforge.net/doc/index.html