This method lets you obtain precise function information at runtime. It performs best for one thread because when there is more than one thread, the overhead measurement from multiple threads can change the application's behavior.
To compile an application with Function Instrumentation:
For a standard Makefile that uses default rules, your file would have the -finstrument-functions and -lprofilingS options for profiling, and it would look similar to this:
CFLAGS += -g -O0 -finstrument-functions LDLIBS += -lprofilingS
If the Makefile doesn't use the default linking and compile rules, flags and/or library, for profiling you'll need to manually add the -finstrument-functions and -lprofilingS options as in the following example:
main.o qcc -g -O0 -finstrument-functions -o main.o main.c binary: qcc -o binary main.o -lprofilingS
For QNX recursive Makefiles, you would also have the -finstrument-functions and profilingS options, and the Makefile would look similar to the following:
CFLAGS += -g -O0 -finstrument-functions LIBS += profilingS
The LIBS variable adds the list of libraries to include into the appropriate compiler options for profiling; you don't use LDFLAGS or LDOPTS to add libraries.
Notice that in the examples above, the -l option appears at the end of each statement. This positioning occurs because qcc doesn't understand the -l option before source and objects files; it must appear at the end.
If the process doesn't finish, you'll have to terminate it manually. Instead of terminating the process, you can terminate the Application Profiler service in the Debug view; the IDE will download the current state of the data.
The Application Profiler isn't optimized for data transfer; each second of application running time can generate up to 2 MB of data.
The IDE creates a profiler session and automatically selects it.