[OT] unofficial MinGW GDB gdb with python released

[ollydbg]

Just a reminder:
In the MinGW mail list:

From: Chris Sutcliffe <[email protected]>
Subject: GDB 7.0.1
Newsgroups: gmane.comp.gnu.mingw.user
Date: 2010-01-07 19:07:37 GMT (5 days, 10 hours and 11 minutes ago)

I've released GDB 7.0.1 for MinGW.  This binary is built from vanilla
GNU GDB sources.

http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.1/gdb-7.0.1-mingw32-bin.tar.gz/download

This time around I've packaged it without the static libraries
(libbfd, libopcodes, libiberty) so as to not conflict with binutils.

Please direct any questions / comments to this mailing list.

Enjoy!

Chris

one problem still exist. too many gdb warning when debugging C::B

[ollydbg]

To reproduce this bug. you can do like this:

1, open codeblocks.cbp in C::B.
2, build the whole project.
3, place a break point in the line 488 of MainFrame::MainFrame() function (in file: F:\cb_svn\src\src\main.cpp)
4. press the "debug" button on the toolbar.
5, when the debugger hit the breakpoint, you need to open the "call stack" dialog.
6, from the "debug log" panel, you can see a lot of warnings.(You need to select: Menu->settings->Compiler and debugger settings-> debugger settings. and select "display debugger's log).

Any comments or suggestions? thanks.

[ironhead]

Hi All,

Just a heads up, I've release a new GDB snapshot:

http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download

This release includes a fix for the symtab / psymtab warnings that will be part of the GDB 7.1 release when it becomes official.

Cheers!

Chris

[Biplab]

Just a heads up, I've release a new GDB snapshot:

http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download

This release includes a fix for the symtab / psymtab warnings that will be part of the GDB 7.1 release when it becomes official.

Thanks Chris. I've been using it since you made this announcement in MinGW mailing list. This build is much better than previous gdb 7 versions.

[oBFusCATed]

ironhead:
Does this release has python scripting enabled?
If it is not enabled can you tell me why?

[ironhead]

ironhead:
Does this release has python scripting enabled?
If it is not enabled can you tell me why?

Python scripting is not enabled.  To be honest I haven't looked in to adding it (I don't use it myself), but I'll take a look at what's involved in adding the support this coming week.

[ollydbg]

thanks chris for your hard work. I will tested tonight.
Edit
It works fine, and the symtab/psymtab bug is fixed. Thanks very much!!

Hi All,

Just a heads up, I've release a new GDB snapshot:

http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download

This release includes a fix for the symtab / psymtab warnings that will be part of the GDB 7.1 release when it becomes official.

Cheers!

Chris

[JZ]

I'm trying to run the GDB debugger for on a Windows platform the first time on a C program and I get the following error message.  

"The debugger executable is not set.  To set it, go to "Settings/Compiler and debugger", switch to the "Programs" tab, and select the debugger program."  

I looked on the Settings page and don't see a "Programs" tab.  What am I missing?

Do I need to separately install GDB?  If so, is there a how to link or can someone point me in the right direction?

[jens]

Do I need to separately install GDB?

Depends on your gcc installation.
But with this error-message the answer is most likely yes.
For a download see the link in one of the previous posts.

To check whether it is set up correctly, look into "Settings -> Compiler and debugger -> Global compiler settings -> [your compiler] -> Toolchain executables" .

[ollydbg]

@Chris Sutcliffe
I find the 7.0.50 version of gdb didn't work correctly.
when I try to view a wxString value in Codeblocks, it takes a lot of time.

Code: [Select]

> whatis m_Buffer
type = wxString
>>>>>>cb_gdb:
> output /c m_Buffer.m_pchData[0]@((wxStringData*)m_Buffer.m_pchData - 1)->nDataLength
{116 't', 101 'e', 115 's', 116 't', 46 '.', 99 'c', 112 'p', 112 'p'}>>>>>>cb_gdb:


When the codeblocks send the command : output xxxxx to gdb, it takes several (more than 10s) to return the string value.

[jens]

@Chris Sutcliffe
I find the 7.0.50 version of gdb didn't work correctly.
when I try to view a wxString value in Codeblocks, it takes a lot of time.

Code: [Select]

> whatis m_Buffer
type = wxString
>>>>>>cb_gdb:
> output /c m_Buffer.m_pchData[0]@((wxStringData*)m_Buffer.m_pchData - 1)->nDataLength
{116 't', 101 'e', 115 's', 116 't', 46 '.', 99 'c', 112 'p', 112 'p'}>>>>>>cb_gdb:


When the codeblocks send the command : output xxxxx to gdb, it takes several (more than 10s) to return the string value.

What happens, if you debug from commandline ?

[jens]

What happens, if you debug from commandline ?

Or if you put the command in the "Command:" text-control and execute it (without running of C::B's gdb-parser) ?

Do you use any debugger related patches or clean sources from trunk.


I just tested it with gdb 7.0.50 as cross-debugger for a wxMSW app on my linux-box and the output occurs immediately after the command is sent to gdb (from inside the program or from the textcontrol).

[jens]

One more question: what do you try to debug ?

I switched to gdb 6.80 on my linux-box, because all 7.0 versions do not work correctly with parts of the C::B sources (at least not when compiled with wxWidgets debug version), 6.80 works fine.

[ollydbg]

@jens
Thanks for the reply.
I use the debugger which was release http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download


I'm just debugging C::B( I'm watching a wxString in CodeCompletion plugin )under C::B.
I will try to create a simple wxWdigets sample code to test it again, also, I will send the command from the "direct input"( once the watches windows was open, it will send these command automatically, so I need to close the watch window when debugging )

[ollydbg]

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.