Application Profiler in IDE 4.5: Installation and Usage Instructions#



Build & Launch#

Sampling Mode #

Sampling is original mode of old Application Profiler, you still can use it. To use basic sampling no recompilation is required. If you want to use calls count instrumentation see below. This mode won't give you precise function times and you rely on the fact the application is running for a long time. It would be almost the same as old profiler except a little bit better editor annotations and compare session support.

Builds Flags#

Launch from IDE#

You application would start as well as Application Profiler monitor, Application Profiler perspective would open and Execution Time would would show data from current session with automatic refresh enabled.

Launch from command line#

You have to be "root" to get sampling from your application launched from command line. By default it would create gmon.out in current directory. You can override location using PROFDIR env var. After application finished or you stopped profiling transfer file on the host and import it into the IDE. Alternately you can launch process on target and attach from IDE. In this case you need to use env var QCONN_PROFILER.

Function Instrumentation Mode for Single Application#

This method allow to get precise functions execution time. Currently it does not work for multi-threaded apps - time spent in different thread would be double-counted.

Build Flags#

If you have code of interrupt handler or critical code you cannot instrument these functions (target would hang if you attempt to run it in file mode, you can still run in kernel trace mode, see below). To avoid instrumenting them, you can either excluded these file from files compiled with -finstrument-functions flags, or you can exclude specific functions using gcc attribute:

__attribute__ ((no_instrument_function))


  void __attribute__ ((no_instrument_function))
interrupt_handler(void * arg) {

Launch from IDE #

Launch from Command line on target #

To launch on target:

Import into IDE#

To import existing trace into the IDE you need:

If you have not built code in the IDE, I recommend perform the following steps:

Importing Trace

Function Instrumentation Mode for System Profiler#

If you want to see functions names in System Profiler timeline view you may want to consider adding this information by Instrumenting you binaries with Function instrumentation library and running in kernel events mode.

Build Flags#

Instead of instrumenting all functions, you can manually insert enter/exit events

Enter event:

#include <sys/trace.h>
void * from = __builtin_return_address(0); // this function address
void * callsite = __builtin_return_address(1); // calling function address
TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, _TRACE_SYSTEM_C >> 10, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)from, (unsigned)callsite);

Exit event:

TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, _TRACE_SYSTEM_C >> 10, _NTO_TRACE_SYS_FUNC_EXIT, (unsigned)from, (unsigned)callsite);

Launch from Command line on target#

Capture trace in specific area of the code#

Start tracelogger in daemon mode, where it is ready to go but not logging.

# tracelogger -d1 -E -w -c -S32M -M -v &
and then in your application, start tracing with
TraceEvent( _NTO_TRACE_START );
and stop with
TraceEvent( _NTO_TRACE_STOP );
TraceEvent( _NTO_TRACE_FLUSHBUFFER ); /* make sure to get the last partial buffer out */
(Using this approach you can use either instrumentation with QPROF_KERNEL_TRACE=1 or manually inserted logging events)

Launch from IDE#

Analyzing Data #

Application Profiler#

It should be self explanatory in most of the cases.

There is a feature description article at: What is New in Application Profiler

User Documentation: Profiling an Application

System Profiler#

Please check this page: Usage of Function Instrumentation in System Profiler

Release Notes for IDE 4.5#

Official Release Notes

How it works#


Target agent (qconn) schedules a task at every 1 ms to check where target process is. "Where the process" defined by its $pc register. To read process registers the reading process must have root permissions. The result of sample (thread id and $pc address) is stored in gmon.out file or transfered directly to IDE through /dev/profiler device.

Call Count instrumentation#

When compiled with -p gcc inserts function _mcount on entry of each functionion, _mcount functions records the call pair and count for call pair. The result is saved in gmon.out file or transfered directly to IDE through /dev/profiler device.

Function Instrumentation #

When compiled with -finstrument-functions gcc inserts two hooks - for entry and exit from the function, thus allowing to measure not only call count but time that took for function to execute. Functions hooks do one of the following: for single app mode - they record call-pair and function enter/exit timing information (measured in ClockCycles()) to the buffers, which is dumped to a file when full. File can be read by IDE in real time or imported to IDE afterwards. The file is usually is referred as ptrace file. File operations can be unsafe for drivers code or interrupt handlers, this mode should be avoided in this case or these functions cannot be instrumented.

In system wide mode (also referred as Kernel Tracing mode) hooks implement trace events. Events are stored in the kernel ring buffer and can be retrieved when trace logger process is running (or read by qconn). The tracelogger output is usually referred as .kev file. Kev file can be viewed in both System Profiler and Application Profiler. It is possible to insert same trace events manually to achieve similar effect for selected sections of code.

If you have any questions or feedback, post into the ide forum.