Community
Participate
Working Groups
1. Create the default executable Hello World program (Managed Make). 2. Edit the program as follows: int main(void) { int a = 3; puts("Hello World"); printf("a is %d\n", a); return 0; } 3. Go the Project->Properties->C/C++ Build->Settings and change the optimization level to -O2 instead of -O0. 4. Build the project and debug using gdb/mi. The first line it can stop at is the "puts" line as the int a = 3 line is optimized away. This is expected. Note that the variable a does not appear in the Variables window. 5. click on the gdb executable and in the Console window type: print a 6. Click back on the debugging executable and hover over the variable a in the source window. 7. Step to the printf line where a is actually used. Again, note that a is not shown in the Variables Window. In steps 5 and 6, gdb knows the value of a is 3 and so does the debug hover somehow, yet the variable a never gets shown in the Variables window. This problem was discovered by the Autotools plug-in because the default compilation options chosen by autotools are: "-g -O2". The problem occurs for CDI as well as DSF so the problem could exist in the gdb/mi protocol itself. It also occurs in 7.0.2.
Can you attach the MI traces that you see? What version of GCC + GDB are you using? This sounds like a gdb problem rather than a CDT problem. CDT relies on the debugger telling it the local variables, so providing this is required to pinpoint the source of the issue.
Created attachment 188956 [details] gdb mi log
(In reply to comment #1) > Can you attach the MI traces that you see? What version of GCC + GDB are you > using? > This sounds like a gdb problem rather than a CDT problem. CDT relies on the > debugger telling it the local variables, so providing this is required to > pinpoint the source of the issue. I added the trace. It appears that DSF does query gdb about the value.
*** Bug 336245 has been marked as a duplicate of this bug. ***