gdb: No symbol "i" in current context - c

Question

While debugging a C program in gdb I have a breakpoint in a for loop. I cannot print the value of "i" ( I get : No symbol "i" in current context.). I can print the value of all the other variables. Is it normal?
Here is the loop:
for (i=0; i < datasize; i++){
if ( feature_mask[i] > 0 ){
k = feature_mask[i] - 1;
if (neighbors[k][nmax-1] != 0){
neighbors[k][nmax-1] = bvalue;
feature_mask[i] = -feature_mask[i];
}
}
}

Answer 1

It has probably been optimised out of your compiled code as you only use feature_mask[i] within the loop.
Did you specify an optimization level when you called your compiler? If you were using gcc, then just omit any -O options and try again.

Answer 2

I encountered this issue recently. I compiled GCC 5.1 and then used it to compile a C++11 codebase. And, although I could step through the program's code in gdb, I couldn't print the value of any variable, I kept getting “No symbol "xyz" in current context” errors, for every variable.
I was using gdb 7.4, but the latest version available at the time was 7.9. I downloaded the latest version of gdb and compiled it (using GCC 5.1) and when using gdb 7.9 I was able to successfully inspect variable values again.
I guess the debug information of GCC 5.1 is incompatible with gdb 7.4.

Answer 3

Make sure the program is compiled without optimization, and with debugging information enabled. It's quite likely that the loop counter ends up in a register.

Answer 4

Check your optimization options. It's possible the GCC could replace the variable with a pointer into feature_mask.

Answer 5

You can try declaring i as volatile. That will prevent some compiler optimizations (and hopefully make i visible inside the debugger).

Answer 6

In case anyone else is using Google's Bazel build system for your project, I'd like to add that if you cannot print any variables from gdb, it may be because you need to properly add the -ggdb and -O0 (update: use -Og instead of -O0 use -O0 over -Og) C build flags using the --copt= option, INSTEAD OF using the --per_file_copt= option. In my case, although they both built and ran just fine, only the --copt= technique allowed me to fully use gdb and print variables, whereas the --per_file_copt= one also allowed me to use gdb but would NOT allow me to print variables.
Note: in the below examples, just replace test with build if you do NOT need to run the unit tests as well.
UDPATE: it turns out, you should prefer -Og over -O0 when doing debugging, so I'm updating these examples accordingly. See here: What's the difference between a compiler's `-O0` option and `-Og` option?.
So, do this:
time bazel test --copt=-ggdb --copt=-O0 \
//my/build/folder1/... //my/build/folder2/...
INSTEAD OF this:
time bazel test --per_file_copt=//my/build/folder1/...,//my/build/folder2/...#-ggdb,-O0 \
//my/build/folder1/... //my/build/folder2/...
...in order to be able to print variables from within gdb.
Again, both of the above techniques build and run just fine, and both allow me to run and use gdb, but only the first one actually allows me to use gdb to its full extent.
Lastly, if the first command above still doesn't work, try adding the --strip=never Bazel flag described here to prevent Bazel from ever stripping debugging information. Now the command will look like this:
time bazel test --copt=-ggdb --copt=-O0 --strip=never \
//my/build/folder1/... //my/build/folder2/...
Reference documentation:
--copt=:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--copt
--per_file_copt:
https://docs.bazel.build/versions/master/command-line-reference.html#flag--per_file_copt
[better, with examples] https://docs.bazel.build/versions/master/user-manual.html#flag--per_file_copt
--strip=never:
https://docs.bazel.build/versions/master/user-manual.html#flag--strip
[my own Q&A] Prefer -Og over -O0 -O0 over -Og for debugging: What's the difference between a compiler's `-O0` option and `-Og` option?