Profiling works by changing how every function in your program is compiled so that when it is called, it will stash away some information about where it was called from. From this, the profiler can figure out what function called it, and can count how many times it was called. This change is made by the compiler when your program is compiled with the `-pg' option.
Profiling also involves watching your program as it runs, and keeping a histogram of where the program counter happens to be every now and then. Typically the program counter is looked at around 100 times per second of run time, but the exact frequency may vary from system to system.
A special startup routine allocates memory for the histogram and sets up a clock signal handler to make entries in it. Use of this special startup routine is one of the effects of using `gcc ... -pg' to link. The startup file also includes an `exit' function which is responsible for writing the file `gmon.out'.
Number-of-calls information for library routines is collected by using a special version of the C library. The programs in it are the same as in the usual C library, but they were compiled with `-pg'. If you link your program with `gcc ... -pg', it automatically uses the profiling version of the library.
The output from gprof gives no indication of parts of your program that
are limited by I/O or swapping bandwidth. This is because samples of the
program counter are taken at fixed intervals of run time. Therefore, the
time measurements in gprof output say nothing about time that your
program was not running. For example, a part of the program that creates
so much data that it cannot all fit in physical memory at once may run very
slowly due to thrashing, but gprof will say it uses little time. On
the other hand, sampling by run time has the advantage that the amount of
load due to other users won't directly affect the output you get.