[OT] unofficial MinGW GDB gdb with python released

[ollydbg]

Steps to build  gdb under MinGW+MSYS can be seen in the wiki: build_gdb_msys_en
Steps to use gdb's python pretty printers and Codeblocks related setup can be seen in the wiki: GDB Pretty printer introduction and setup

You must install Python 2.7.5 release 32bit version on your system, as my build was linked to this python release.

2016-01-30
New release, the pre-build binary is gdb2016-01-30.zip and the patches are gdb2016-01-30patches.zip, it fix some bugs which does not exists in 2014-05-23 version, such as this one: 17659 – [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event. And the binary is build with G++ compiler. As you know, GDB is migrating to C++.

2014-05-23
gdb2014-05-23.zip with patches against GDB GIT HEAD released. The main change in my patches from 2014-01-14 is that is fix a Bug 15806 – Some fields in async MI events get escaped twice.
2014-01-14
A new release with binary achieve gdb2014-01-14.zip and patches against gdb git head gdb2014-01-14patches.zip. The main change from 2013-10-09 release is that I remove my workaround patch for GDB bug #12127, since I think it was fixed in the GDB main stream, see some descriptions in Comment 6.
2013-10-09
New release for GDB, the binary achieve is in gdb2013-10-09.zip, the patches against GDB cvs 2013-10-04 is in gdb2013-10-09patches.zip, note I now use git to generate a serial patches, you can either apply them one by one manually, or by "git am" command.
MinGW GCC 4.7.0 and later has thiscall calling convention for C++ class member function, but GDB can not handle this correctly, see details in: FYI: GDB has a big bug to support MinGW GCC (4.7.x and later), my release fixes this bug by automatically detect the version of gcc which build the debugee, and fetch the correct calling convention in GDB. All the binaries are build from MSYS + mingw-builds-x32-4.8.1-posix-dwarf-rev5 with statically link to iconv, expat, zlib librares.

2013-06-08
New release for GDB cvs 2013-06-08, now I have a new site for download in gdbmingw, and the binary achieve is: gdb2013-06-08.7z and the patch is gdb2013-06-08.7z. This patch is quite small, I only try to fix two issues, one issue is the crash problem when GDB try to show an un-initialzed local variable, see Bug 12127 – gdb with python support still get crash on showing uninitialized local variables, you set run the command "set print elements xxx", the xxx is a reasonable number. The other issue it the performance regression workaround, see Bug 15412 – Performance regression in "info {func,var,types} foo" (mostly info types)..  The binaries is build from PCX's MinGW 4.7.3 suite (with an updated libmsvcrt.a to fix an missing export function issue).

2013-02-04
gdb2013-02-04.zipwith patch gdb2013-02-04.patch, note the change file name display patch was in cvs trunk now, so you can use the command below to alter the filename display format, either "relative", "basename" or "absolute". (note, the word "backtrace" was removed in the command compared to 2012-05-22 release.

Code

set filename-display absolute

2012-12-16
gdb cvs 2012-12-15 using the patch 2012-12-15.patch

2012-08-19
gdb2012-08-17.zip build using the patch 2012-08-17.patch against gdb cvs head.

2012-05-22
gdb2012-05-22now build from xunxun's mingw gcc 32bit 4.6.3 release.
Here is the total patch file patch against gdb cvs.
It is linked to python 2.7.3 library, so you need to have python 2.7.3 installed on your system.
To see the full file path on the backtrace command, you need to run the command:

Code

set backtrace filename-display absolute

See: Jan Kratochvil - Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file for more details and other options.


2012-02-16
gdb2012-02-16.7z now build from xunxun's gcc 4.6.3 release.
The total patch file against vanilla gdb cvs(I use gdb's read only git clone) can be found in: gdb2012-02-16.patch
I find a regression about showing full file name in bt command since 2011-12-12, because the patch: iam ahal - Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file does not fully solve the problem: show full paths on backtrace.

This release fix the regression and works OK now.

Note: this issue is only related to debug a dll (which build with relative file source paths) under c::b, because c::b need an full name to open a source file, see more details: show full paths on backtrace.


2012-01-19
HAPPY CHINESE NEW YEAR (Dragon year is coming)
The new pre-build binary package can be found in gdb2012-01-19.7z, it is gdb's latest cvs version with my patch applied.
I remove the hard-coded relocated code, because gdb can relocate correctly, see: Doug Evans - Re: Possible fix for mingw32 directory relocation problems related discussion for more details. The other parts of the patch include: work around the crash problem of local variable print, adjust some minor file paths of call-stack print.


2011-11-08 release
Pre-build binary can be found in gdb2011-11-08cvs.7z

GDB built with python support, you need to install python 2.7.2 in your system. This build include some patches to handle file paths problem under Windows system.

A patch to accelerate the file path comparasion, see: asmwarrior - Re: [RFC] Avoid calling gdb_realpath if basenames are different and Re: configure file to debug codecompletion plugin

Watchpoint can be used in both gdb.exe and gdbserver.exe, see: brobecke - src/gdb/gdbserver ChangeLog win32-i386-low.c

The total diff file to the gdb cvs head source can be found in: gdb2011-11-08cvs.diff

2011-10-09
Update to the latest gdb cvs, and the patches I used was also contains in the achieve. see: gdb2011-10-09cvs.zip, this release was build with python 2.7.2, expat cvs library(static), iconv cvs library(static). I build it with TDM GCC 4.5.2sjlj, and with -O2 enabled. (It should be faster than my previous releases).
Note: I found that this revision has some tiny bugs. E.g. when step, it will complain some memory reading errors, so I still suggest using the 2011-08-10 version until I update to a new revision.

2011-08-10
To solve the problem I stated in load gdb's own python script support, I have hack the gdb's data search directory. The full patch was gdb2011-08-08.patch, You need to extract this package to your installed MinGW folder, when starting gdb, the python script under "YourMinGW/share/gdb/python/gdb" will be automatically loaded. Thus, you can qurey pretty-printer information by the command: "info pretty-printer". such as the log below:

>>>>>>cb_gdb:
> info pretty-printer
global pretty-printers:
  libstdc++-v6
    __gnu_cxx::_Slist_iterator
   ......
    std::vector
    std::weak_ptr
  lookup_function
>>>>>>cb_gdb:

The package can be download from GDB2011-08-10cvs.7z.

2011-08-04
NOTE: This version has some issue on backtrace command, I removed the package on Google Host site, and Please use a previous version instead until I fix this issue. Sorry for the inconvenience.(This issue is fixed)
GDB7.3.50.20110804-cvs.7z build from gdb git master source, and with the patches to fix windows breakpoint and other problems, see:
http://sourceware.org/ml/gdb/2011-06/msg00074.html
http://sourceware.org/ml/gdb/2011-07/msg00041.html
show full paths on backtrace
for more details and patches.
This version I build with static expat library, and you should have python 2.7.x installed on your system.
You can download the binaries from: Download, Have Fun!!!
Note: please pay attention to this issue when using gdb under Codeblocks:question about exit the debugee when debugging.

2011-06-06
gdb-7.3.50.20110604 build from gdb git source.
build against python 2.7.1, expat cvs.
As the latest gdb/linespec.c has bugs under Windows, so I use an old version of linespec.c to solve the problem.
see: http://sourceware.org/ml/gdb/2011-06/msg00024.html
This package also contains all the python related script libraries and dlls, so install a separate python is not necessary.
The download link is: gdb-7.3.50.20110604.7z

2011-04-02
new version: gdb-7.2.50.20110401.7z

2011-01-10
build a new gdb cvs version. see gdb7.2.50.20110110-cvs.7z
link against expat(cvs,static) and python(2.7.1,dynamic), build from MSYS and PcX's MinGW GCC 4.5.2.
BTW: I have wrote the full steps to build the gdb under MinGW+MSYS, see:
build_gdb_msys_cn (In Chinese Language, and Maybe I will add a English version somedays, and also you can use the Google translation Google Translate Version.
Happy New Year!!!

2010-12-13
build a new version link to the python 2.7.1 lib, you can download from:gdb-7.2.50.20101213.7z You need to have python 2.7.1 installed on your system.

I'm really appreciate to xunxun1982's help!!!

2010-09-05
since the official gdb 7.2 is released, then Loaden has build this one, he just build it from the official gdb 7.2 source(no extra patches is used). It is linked against expat static library, also python pretty script is enabled. (the package has python script for std library and wxwidgets). You can download it from: gdb-7.2.7z
Thanks loaden for the build. for How to use GDB with python under Codeblocks, see:
Use GDB python under Codeblocks

2010-07-09
The new gdb file has uploaded to gdb-7.2.50.20100708-cvs.7z, it is now linked against python 2.7. Many Thanks to loaden for the build！！！

2010-06-24
The new gdb file has uploaded to http://qp-gcc.googlecode.com/files/gdb7.1.50.20100623cvs.7z
And the new introduction wiki page: http://code.google.com/p/qp-gcc/wiki/GDB

2010-06-13:
A new version of gdb with python support release. see more details here:
gdb-7.1.50.20100613 with python

2010-05-22:
Hi, all. I have successfully built the mingw gdb 7.1.50 snapshot from the source gdb-7.1.50.20100521. tar.bz2 link against expat static library (build under Loaden's mingw 4.4.4 and Msys). You can download it from gdb-7.1.50.20100521.7z
It is just runs fast as gdb 7.0.1.
As you know, the 7.1 version has some problems(time delay when showing wxString), this gdb 7.1.50 don't have this problem.
Have a try!!

For older version of GDB
GDB MinGW GDB 7.0.1, this 7.0.1 version is link to dynamic expat library, so, you need a expat dll (see below). you will need libexpat-2.0.1-1-mingw32-dll-1.tar.gz, available here:libexpat-2.0.1-1-mingw32-dll

[ollydbg]

I just notice that under GDB 7.0, the loading time of a debuggee (I'm debugging codeblocks under codeblocks) is only 10 seconds.

But under gdb 6.8.3, it's about 30 seconds.

So, it's much faster.

Edit

I'm sorry, that I think the TDM-GCC 4.4.0 and GDB7.0 has some conflict. because, in GDB 7.0, I can't set breakpoint anymore.

see the debug log:

Code

> set args --debug-log --no-check-associations -ns -nd
>>>>>>cb_gdb:
> break "F:/cb_svn/src/plugins/codecompletion/nativeparser.cpp:1422"
No source file named F:/cb_svn/src/plugins/codecompletion/nativeparser.cpp.
Breakpoint 2 ("F:/cb_svn/src/plugins/codecompletion/nativeparser.cpp:1422) pending.
>>>>>>cb_gdb:

 

[Jenna]

I'm sorry, that I think the TDM-GCC 4.4.0 and GDB7.0 has some conflict. because, in GDB 7.0, I can't set breakpoint anymore.

see the debug log:

Code

> set args --debug-log --no-check-associations -ns -nd
>>>>>>cb_gdb:
> break "F:/cb_svn/src/plugins/codecompletion/nativeparser.cpp:1422"
No source file named F:/cb_svn/src/plugins/codecompletion/nativeparser.cpp.
Breakpoint 2 ("F:/cb_svn/src/plugins/codecompletion/nativeparser.cpp:1422) pending.
>>>>>>cb_gdb:

 

Is this only the output, or does it really not break there ?

It's the normal output you get if you set a bp in not yet loaded libraries and it looks exactly the same as with gdb 6.8.50 on linux, and here it works.

[oBFusCATed]

Will test on arch linux today, hope it works

[Jenna]

I just build a debian-package of the gdb-sources.
I did not patch anything, just plain sources.

I installed and it works as expected.
Same behaviour than with 6.8.50, as far as I can see. Just one bp (in nativeparser.cpp:1422), some steps, step out, watch some variables, everything seems to work fine.

[ollydbg]

Here is the full output of the debug log.

It seems the Mingw gdb7.0 still can't reach the breakpoint.



[attachment deleted by admin]

[mariocup]

Hi ollydbg,

I had a similar problem with ARM gdb that I build myself under windows. In the gdb sources there was a bug in getting the relative path for setting breakpoints. After putting the following code in the file util.c it worked also under windows. The strange thing is that the binary version of gdb 6.8 worked without changes for x86.

Code

#if !defined(HAVE_REALPATH)
#if defined (_WIN32) || defined(__MINGW32__)
# define WIN32_LEAN_AND_MEAN
# include <windows.h> /* for GetFullPathName */
# endif
#endif
....

char *
gdb_realpath (const char *filename)
{
...
 	 	#if !defined(HAVE_REALPATH)
  		# if defined (_WIN32) || defined(__MINGW32__)
  		/* The MS Windows method. If we don't have realpath, we assume we
  		don't have symlinks and just canonicalize to a Windows absolute
  		path. GetFullPath converts ../ and ./ in relative paths to
  		absolute paths, filling in current drive if one is not given
  		or using the current directory of a specified drive (eg, "E:foo").
  		It also converts all forward slashes to back slashes. */
  		{
  		char buf[MAX_PATH];
  		char *basename;
  		DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename);
  		if (len == 0 || len > MAX_PATH - 1)
  		return strdup (filename);
  		else
  		{
  		return strdup (buf);
  		}
  		}
#endif
#endif

[ollydbg]

Hi ollydbg,

I had a similar problem with ARM gdb that I build myself under windows. In the gdb sources there was a bug in getting the relative path for setting breakpoints. After putting the following code in the file util.c it worked also under windows. The strange thing is that the binary version of gdb 6.8 worked without changes for x86.

Code

#if !defined(HAVE_REALPATH)
#if defined (_WIN32) || defined(__MINGW32__)
# define WIN32_LEAN_AND_MEAN
# include <windows.h> /* for GetFullPathName */
# endif
#endif
....

char *
gdb_realpath (const char *filename)
{
...
 	 	#if !defined(HAVE_REALPATH)
  		# if defined (_WIN32) || defined(__MINGW32__)
  		/* The MS Windows method. If we don't have realpath, we assume we
  		don't have symlinks and just canonicalize to a Windows absolute
  		path. GetFullPath converts ../ and ./ in relative paths to
  		absolute paths, filling in current drive if one is not given
  		or using the current directory of a specified drive (eg, "E:foo").
  		It also converts all forward slashes to back slashes. */
  		{
  		char buf[MAX_PATH];
  		char *basename;
  		DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename);
  		if (len == 0 || len > MAX_PATH - 1)
  		return strdup (filename);
  		else
  		{
  		return strdup (buf);
  		}
  		}
#endif
#endif

Thanks.

I will report this issue on the MinGW Mail list.

Also, another question is:
How can I build a gdb.exe, Is it easy to do?
for now, I can download the source code from
http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0/gdb-7.0-mingw32-src.tar.gz/download

Thanks again!

[ollydbg]

In the MinGW maillist. someone said:

> I've packaged GDB-7.0 for MinGW:
> >
> > http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0/gdb-7.0-mingw32-src.tar.gz/download
> > http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0/gdb-7.0-mingw32-bin.tar.gz/download
> >
> >  
Excellent!
Now I can debug again using Code::Blocks.
I was not able to do this with previous GDB versions for MinGW since I
switched to 4.4.0.
Thanks.
    Brecht

String thing , it seems this guy can debug under GDB 7.0. and can't debug under GDB 6.8.

Edit

You can view the thread under this webpage:

http://news.gmane.org/gmane.comp.gnu.mingw.user

[killerbot]

It works for me. (TDM-GCC 4.4.0 and GDB 7.0 from the above link)

However I also noticed something strange.

Tooltipped during debugging on an std::string (local variable).  [the ..... mean there is more stuff there]

Code

ContinueDebugEvent .......
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
ContinueDebugEvent ....
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
"Group"

Notice the "Group" at the end, the correct value of the string.

With another string it is ok.

[ollydbg]

It works for me. (TDM-GCC 4.4.0 and GDB 7.0 from the above link)

However I also noticed something strange.

Tooltipped during debugging on an std::string (local variable).  [the ..... mean there is more stuff there]

Code

ContinueDebugEvent .......
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
ContinueDebugEvent ....
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
"Group"

Notice the "Group" at the end, the correct value of the string.

With another string it is ok.

Thanks.
Hello, killerbot, if you just create a simple console project, then it works.
But could you please test by setting a breakpoint in the codeblocks' source code? this case, it didn't work here.

Here is the main step:

1, install TDM-MinGW 4.4.0
2, unzip the GDB.exe 7.0 binary package, and paste to the TDM-MinGW folder.(some files will be overwritten)
3, I have try both  CB_trunk, CB_debuger_branch, CB_nightly_build version.
4, You open the codeblocks.cbp file, and set a breakpoint under any cpp file, and start debugging.


the result is:
the breakpoint can't be set correctly, and the debugee keeps running...with no break.

 

[vix]

I have the same problem (execution doesn't stop at breakpoint during debug) with gdb 6.8.
Here is the gdb log

Code

PATH=.;C:\Programmi\MinGW\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\programmi\ati technologies\ati control panel;c:\programmi\zipgenius 6\;c:\programmi\ivi\bin;c:\vxipnp\winnt\bin;C:\Siemens\Sinumerik\HMI-Advanced\mmc2;C:\Siemens\Sinumerik\HMI-Advanced\hmi_adv;C:\Siemens\Sinumerik\HMI-Advanced\add_on\MH
Command-line: C:\Programmi\MinGW\bin\gdb.exe -nx -fullname  -quiet -args SWset_dbg.exe
Working dir : H:\MyWorkingdir\MyProject\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined in loaded symbols.
>>>>>>cb_gdb:
> source C:\Programmi\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory H:/MyWorkingdir/MyProject/
>>>>>>cb_gdb:
> break "H:/MyWorkingdir/MyProject/main.c:149"
Breakpoint 1 ("H:/MyWorkingdir/MyProject/main.c:149) pending.
Function "H:/MyWorkingdir/MyProject" not defined in loaded symbols.
>>>>>>cb_gdb:
> run
gdb: win32_init_thread_list
[New thread 3632.0x944]
[New thread 3632.0x174]
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to thread 3632.0x174]
0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> info locals
No symbol table info available.
>>>>>>cb_gdb:
> info args
No symbol table info available.
>>>>>>cb_gdb:
> bt 30
#0  0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1  0x7c961e68 in ntdll!KiIntSystemCall () from C:\WINDOWS\system32\ntdll.dll
#2  0x00000005 in ?? ()
#3  0x00000004 in ?? ()
#4  0x00000001 in ?? ()
#5  0x003fffd0 in ?? ()
#6  0x00000246 in ?? ()
#7  0xffffffff in ?? ()
#8  0x7c91e920 in strchr () from C:\WINDOWS\system32\ntdll.dll
#9  0x7c961e88 in ntdll!KiIntSystemCall () from C:\WINDOWS\system32\ntdll.dll
#10 0x00000000 in ?? ()
>>>>>>cb_gdb:
> quit

I can see some "Function not defined" and "Breakpoint pending" messages, but I don't know what they mean.

This problem happens on WinXP Pro SP2.
Also one of my friends has the same problem.
I'd like trying with new gdb 7.0, but I don't know where to find a binary release, or how to compile it by myself from the sources.

[ollydbg]

@vix
If you install the TDM-MinGW 4.4.0 package( this has already include a gdb.exe 6.8.3), it should works quite well.

[MortenMacFly]

But could you please test by setting a breakpoint in the codeblocks' source code? this case, it didn't work here.

Works fine, here.
I set a BP in C::B's "main" function -> stops.
While stopped I set a BP in a sub-method that'll be called certainly and hit continue -> stops.

For me all is OK?! (Using TDM 4.4.0, GDB 7.0 and C::B's debugger branch.)

BTW: Try really removing TDM before installing it freshly (from the single packages). Cause GDB7 has some files in different folders now.

[vix]

@vix
If you install the TDM-MinGW 4.4.0 package( this has already include a gdb.exe 6.8.3), it should works quite well.

I've already installed the TDM-MinGW 4.4.0 package (tdm-mingw-1.905.0-4.4.0-2.exe file).

I did some tests with the "Hello World" example: the debugger stops at breakpoint only if the project files and the debugger are in the same unit (both in C: disk), and the path doesn't contain spaces. If I move the project to another unit (Z:\), or to a path with spaces (for example  \Documents and Settings\...) the debugger doesn't stop anymore at the breakpoint.