IDB can help debug an optimized program that is compiled with the -g option. However, some of the information about the program may be inaccurate. In particular, the locations and values of variables are often not correctly reported, because the common form of debug information cannot fully represent the complexity of the optimizations provided by the -O1/2/3 options.
To avoid this limitation, compile the program with an Intel compiler, specifying both the -g and -debug extended options, in addition to the desired -O1/2/3 optimization option. This causes the generation of more advanced (but less commonly supported) debug information that enables the following:
Giving correct locations and values for variables, even if they are in registers or at different locations at different times. Note the following:
Some variables may be optimized away or converted to data of a different type, or their location may not be recorded at all points in the program. In these cases, printing a variable will yield <no value>.
Otherwise, the values and locations will be correct, though registers have no address, so a print &i command may print a warning.
Most variables and arguments are undefined during function prologues and epilogues, though a stop in main command will usually stop the program after the prologue.
Shows inline functions in stack traces, identified by the inline keyword. Note the following:
Only the function at the top of the stack and functions that make regular (non-inline) calls show instruction pointers, because other functions share a hardware-defined stack frame with the inline functions that they called.
The return instruction will only return control to a function that made a non-inline call using a call instruction, because inline calls have no defined return address, particularly when their instructions are mixed with those of other functions.
The up, down, and func commands work as usual.
Allows you to set breakpoints in inlined functions.
The following limitation exists:
Optimization often prevents instructions for a source line being generated in consecutive locations. This is particularly true for the Intel® Itanium® architecture. When stepping through such code, the program will tend not to stop at each source line in turn, but rather it will stop each time a change in source line occurs.