Home » Language IDEs » CDT » GDB breakpoints and stack trace not shown in CDT
|GDB breakpoints and stack trace not shown in CDT [message #967766]
||Thu, 01 November 2012 21:23
| Chris Bruniges
Registered: April 2012
Location: Wellington, New Zealand
I have a fresh install with current updates Eclipse for C developers (4.2.x) and avr-eclipse (for a specific microprocessor I'm using).|
I am debugging using gdb-server / avr-gdb.
I am having trouble seeing the following in the CDT debug view:
- stack trace
- variables (local or specifically added global)
At first I thought it was something clobbering the stack, but I can correctly retrieve the stack from gdb console (I've noted the requests from me as opposed to what CDT does automagically. Also, some names have been altered as it's proprietary code):
info stack // I typed this
113-interpreter-exec console "info stack"
~"#0 main () at ../projectMain_atmega128.c:167\n"
#0 main () at ../projectMain_atmega128.c:167
In the first case, it displays correctly in the 'debug' window.
Inserting a breakpoint (by double clicking the source) and running to it, the debugger stops correctly. Eclipse instructs GDB to insert the following (correctly):
101-break-insert -t main
However, the breakpoint is not displayed in the 'breakpoints' window, and the function variables are not shown in the 'Variables' window (when execution is suspended at the breakpoint). These both have no entries in them. The Debug window shows project->gdbserver (suspended)->thread  and stops there. It doesn't give the function name, and the associated line in foo() (where we double clicked the breakpoint) is not highlighted.
I can correctly retrieve the stack, breakpoints and variables directly from gdb using:
info stack // I typed this
120-interpreter-exec console "info stack"
~"#0 foo (pUnused=0x0, psUpdate=0x800531) at ../foo.c:51\n"
#0 foo (pUnused=0x0, psUpdate=0x800531) at ../foo.c:51
// Removed by user :)
~"#15 0x000052f8 in common_ParseComms () at ../projectCommon_mod.c:18\n"
#15 0x000052f8 in common_ParseComms () at ../projectCommon_mod.c:18
~"#16 0x00004eca in main () at ../projectMain_atmega128.c:215\n"
#16 0x00004eca in main () at ../projectMain_atmega128.c:215
info locals // I typed this
122-interpreter-exec console "info locals"
~"acBuf = \"\\373d7\\017\\334\\017\\000\\000\\016\\000\\000\\001\\000Z\\355\\017\\326\\017Z\\355\\000\\004[=\\017\\350\\017\\353Z\\355\\017\\350\\017\\353\\004P\\f|$\\005\\346\\004\\000\\000|\\f\\372\\017\\017\", <incomplete sequence \\373>"
acBuf = "\373d7\017\334\017\000\000\016\000\000\001\000Z\355\017\326\017Z\355\000\004[=\017\350\017\353Z\355\017\350\017\353\004P\f|$\005\346\004\000\000|\f\372\017\017", <incomplete sequence \373>~"\n"
info break // I typed this
123-interpreter-exec console "info break"
~"Num Type Disp Enb Address What\n"
Num Type Disp Enb Address What
~"1 breakpoint keep y 0x00001a14 in foo at ../foo.c:51\n"
1 breakpoint keep y 0x00001a14 in foo at ../foo.c:51
~"\tbreakpoint already hit 1 time\n"
breakpoint already hit 1 time
Seeing as GDB knows about this all correctly, I'm leaning towards the link between gdb and eclipse?
I think I have all my source files included properly, both in the main Eclipse project and according to the GDB trace, but they are spread out over multiple static library generating Eclipse projects, which adds an interesting twist. Could this explain breakpoints / variables / stack trace not showing up?
What do people recommend doing to further diagnose?
Thanks in advance,
Current Time: Sun May 19 11:55:16 EDT 2013
Powered by FUDForum
. Page generated in 0.01422 seconds