10.2. Program variables
The most common kind of expression to use is the name of a variable
in your program.
Variables in expressions are understood in the selected stack frame
(refer to Section 8.3 Selecting a frame); they must be either:
This means that in the function
int b = test ();
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.
There is an exception: 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:
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:
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 off all optimization
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, either recompile without optimizations, or use a
different debug info format, if the compiler supports several such
formats. For example, gcc, the gnu C/C++ compiler
usually supports the -gstabs+ option. -gstabs+
produces debug info in a format that is superior to formats such as
COFF. You may be able to use DWARF 2 (-gdwarf-2), which is also
an effective form for debug info. .