User forums > General (but related to Code::Blocks)

[OT] unofficial MinGW GDB gdb with python released

<< < (16/35) > >>

Jenna:

--- Quote from: ollydbg on February 12, 2010, 12:47:59 am ---Ok, gdb 7 works fine when I debug a simple wxWdigets created from the "project wizard" in Codeblocks, there's no time lag here.

So, the problem is, it works badly when I'm debugging some C::B's source.

--- End quote ---

That's why I switched back to 6.80 on linux.
I wanted to debug wxWidgets (due to bugs in wx-2.9 and trunk), but the debugger did not stop at my breakpoints, I got the output that says it is at line xxx and C::B believes that (yellow triangle), but in fact the debugger did not really stop.
I had this issues with gdb 7.0.1 from debian repository.

ollydbg:
This version of gdb http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.1/gdb-7.0.1-mingw32-bin.tar.gz/download works nice (except the "symtab warning" problem) when I debug CodeCompletion plugin.

ironhead:
Hopefully the 7.1 release will work out better for you (when it becomes official).  The 7.0.50 build is working for me, but then I'm not trying to debug C::B. ;)

ollydbg:
I just download the gdb snapshot from:

ftp://sourceware.org/pub/gdb/snapshots/branch/

gdb-weekly-7.0.90.20100223.tar.bz2

And follow the steps in :

http://dev.zhourenjian.com/blog/2009/03/11/compiling-gdb-debugger-in-windows.html

Then, I build the gdb.exe myself.
 It seems 7.0.90.20100223 runs faster, and without the lag problems when showing wxString value when debugging CodeCompletion plugin.


Note
Wait, I have noticed that:
when I have three wxString variable listed in watches window, this self-built of gdb still runs slower than the 7.01 version... :(

ollydbg:
@ironhead:
I have build  both
branch/gdb-weekly-7.0.90.20100223.tar.bz2
and
current/gdb-7.1.50.20100223

But both work a bit slow when showing the wxString value(Even I entered the command from the command line)

For example, if m_Str is a wxString variable in CodeCompletion

--- Code: ---output /c m_Str.m_pchData[0]@((wxStringData*)m_Str.m_pchData - 1)->nDataLength

--- End code ---

Did you know whether there is a slow down when parsing the command input??? or there are other bugs? How can I report this bug?

Navigation

[0] Message Index

[#] Next page

[*] Previous page