News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

[OT] unofficial MinGW GDB gdb with python released

Started by ollydbg, October 08, 2009, 08:21:52 AM

Previous topic - Next topic

ollydbg

Just a reminder:
In the MinGW mail list:

QuoteFrom: Chris Sutcliffe <ir0nh34d@...>
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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

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

Quote from: ironhead on February 07, 2010, 03:16:07 PM
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. :)
Be a part of the solution, not a part of the problem.

oBFusCATed

ironhead:
Does this release has python scripting enabled?
If it is not enabled can you tell me why?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ironhead

Quote from: oBFusCATed on February 07, 2010, 06:52:20 PM
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

#66
thanks chris for your hard work. I will tested tonight.
Edit
It works fine, and the symtab/psymtab bug is fixed. Thanks very much!!
Quote from: ironhead on February 07, 2010, 03:16:07 PM
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

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

JZ

#67
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?


Jenna

Quote from: JZ on February 09, 2010, 06:02:45 AM
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.

> 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.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Jenna

Quote from: ollydbg on February 11, 2010, 03:33:38 PM
@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.

> 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 ?

Jenna

Quote from: jens on February 11, 2010, 07:55:55 PM
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).

Jenna

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 )



If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.