User forums > Using Code::Blocks

Debug watches problem (Incomplete type)

<< < (2/3) > >>

artoj:

--- Quote from: Multinode Nick on November 08, 2006, 07:30:51 pm ---Like as you said, I noticed that gdb seems to manage wxString and wxPoint but it's blind in front of wxBitmap and wxImage.

wxWidgets seems to be well integrated in Code::Blocks, but how can we use it efficiently if we cannot debug our interfaces?

--- End quote ---

New watch types can be added with the debugger scripts. In Code::Blocks' installation, the file which gets executed at the start of the debugging session (and registers the types) is in share\CodeBlocks\scripts\gdb_types.script. And the language used is called Squirrel, more info at the Wiki.


--- Quote ---But if you're right, how do you debug your developments without a good Watches window? It must be very time consuming without it...

--- End quote ---

The questions should be, "how do I debug something without any debugging features available", which is the Windows XP 64-bit edition with the current Mingw.

dmoore:
the incomplete type is a GDB bug. you just CAN'T inspect some variables (you can see it in the debuggers console window if you have it switched on)

you could try an older version of GDB - I've read that 5.x versions don't have the incomplete type problem (but they do have other problems and may not work with CB at all...)

David Perfors:

--- Quote from: Multinode Nick on November 08, 2006, 07:30:51 pm ---Thank you mispunt,

But if you're right, how do you debug your developments without a good Watches window? It must be very time consuming without it...

Like as you said, I noticed that gdb seems to manage wxString and wxPoint but it's blind in front of wxBitmap and wxImage.

wxWidgets seems to be well integrated in Code::Blocks, but how can we use it efficiently if we cannot debug our interfaces?

--- End quote ---
It is a real pain to debug with GDB (my opinion). When I debug, I put messages on a console, and I step through code to see where things go wrong. That is no problem in code that I own, but in code of wxWidgets or some other lib, it is a real pain....
Perhaps we can work on a set of wxWidgets types that could be watched by C::B/GDB...

mandrav:

--- Quote from: dmoore on November 08, 2006, 08:10:45 pm ---the incomplete type is a GDB bug. you just CAN'T inspect some variables (you can see it in the debuggers console window if you have it switched on)

--- End quote ---

It's actually the combination of the gcc version used to compile the program and the gdb version. After all, if you think about it, the debugger only knows about the debug symbols the compiler has put in the binary you 're debugging ;).

If you google for this issue you will find lots of references, like this similar post.

dmoore:

--- Quote from: mandrav on November 09, 2006, 09:03:14 am ---
--- Quote from: dmoore on November 08, 2006, 08:10:45 pm ---the incomplete type is a GDB bug. you just CAN'T inspect some variables (you can see it in the debuggers console window if you have it switched on)

--- End quote ---

It's actually the combination of the gcc version used to compile the program and the gdb version. After all, if you think about it, the debugger only knows about the debug symbols the compiler has put in the binary you 're debugging ;).

If you google for this issue you will find lots of references, like this similar post.

--- End quote ---

I'll accept that. my point was that no amount of hacking in CB will get around it. unlike wxString, which actually returns pointer/member info when you write "output str" even if it isn't quite what you want, wxBitmap returns nothing when you write "output bmp". I suspect that the complexity of the ABSTRACT/DYNAMIC macros used to declare the wxBitmap type is the cause.

BTW I finally figured out how to display debugger output from fortran programs for variables in modules. unfortunately the "output" command refuses to cooperate and I can only use the gdb "x" command with appropriate formatting. This will be a pain to get working in the watch (probably not worth the effort)

EDIT: you probably know this already, but gdb has a little "macro" language allowing you to define your own commands. link: http://computing.ee.ethz.ch/sepp/gdb-6.5-mo/gdb_116.html#SEC228. maybe this could be used to handle some of the parsing work?

Navigation

[0] Message Index

[#] Next page

[*] Previous page