Debugging with GDB Manual The GNU Source-Level Debugger (769148-001, March 2014)

Variables in expressions are understood in the selected stack frame (see “Selecting a frame”
(page 51); they must be either:
• global (or file-static)
or
• visible according to the scope rules of the programming language from the point of execution
in that frame
This means that in the function
foo (a)
int a;
{
bar (a);
{
int b = test ();
bar (b);
}
}
you can examine and use the variable a whenever your program is executing within the function
foo, but you can only use or examine the variable b while your program is executing inside the
block where b is declared.
However, you can refer to a variable or function whose scope is a single source file even if the
current execution point is not in this file. But it is possible to have more than one such variable or
function with the same name (in different source files). If that happens, referring to that name has
unpredictable effects. If you wish, you can specify a static variable in a particular function or file,
using the colon-colon notation:
file::variable
function::variable
Here file or function is the name of the context for the static variable. In the case of file
names, you can use quotes to make sure GDB parses the file name as a single word. For example,
to print a global value of x defined in 'f2.c':
((gdb)) p 'f2.c'::x
This use of '::' is very rarely in conflict with the very similar use of the same notation in C++. GDB
also supports use of the C++ scope resolution operator in GDB expressions.
WARNING! Occasionally, a local variable may appear to have the wrong value at certain points
in a function just after entry to a new scope, and just before exit.
You may see this problem when you are stepping by machine instructions. This is because, on
most machines, it takes more than one instruction to set up a stack frame (including local variable
definitions); if you are stepping by machine instructions, variables may appear to have the wrong
values until the stack frame is completely built. On exit, it usually also takes more than one machine
instruction to destroy a stack frame; after you begin stepping through that group of instructions,
local variable definitions may be gone.
This may also happen when the compiler does significant optimizations. To be sure of always
seeing accurate values, turn o all optimization when compiling.
Another possible effect of compiler optimizations is to optimize unused variables out of existence,
or assign variables to registers (as opposed to memory addresses). Depending on the support for
such cases offered by the debug info format used by the compiler, GDB might not be able to
display values for such local variables. If that happens, GDB will print a message like this:
No symbol "foo" in current context.
To solve such problems, recompile without optimizations. See “Compiling for debugging” (page 28).
Program variables 59