What does the -p and -g flag in compiler?

Question

I have been profiling a C code and to do so I compiled with -p and -g flags. So I was wandering what do these flags actually do and what overhead do they add to the binary?

Answer 1

Assuming you are using GCC, you can get this kind of information from the GCC manual

http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options

-p

Generate extra code to write profile information suitable for the analysis program prof. You must use this option when compiling the source files you want data about, and you must also use it when linking.

-g

Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging information.

On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.

Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

Answer 2

-p provides information for prof, and -pg provides information for gprof.

Let's look at the latter. Here's an explanation of how gprof works, but let me condense it here.

When a routine B is compiled with -pg, some code is inserted at the routine's entry point that looks up which routine is calling it, say A. Then it increments a counter saying that A called B.

Then when the code is executed, two things are happening. The first is that those counters are being incremented. The second is that timer interrupts are occurring, and there is a counter for each routine, saying how many of those interrupts happened when the PC was in the routine.

The timer interrupts happen at a certain rate, like 100 times per second. Then if, for example, 676 interrupts occurred in a routine, you can tell that its "self time" was about 6.76 seconds, spread over all the calls to it.

What the call counts allow you to do is add them up to tell how many times a routine was called, so you can divide that into its total self time to estimate how much self time per call. Then from that you can start to estimate "cumulative time". That's the time spent in a routine, plus time spent in the routines that it calls, and so on down to the bottom of the call tree.

This is all interesting technology, from 1982, but if your goal is to find ways to speed up your program, it has a lot of issues.