[OT] unofficial MinGW GDB gdb with python released

[Jenna]

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.

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 Select Expand


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


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?

[ironhead]

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?

I'm not sure if the slowdown is expected or not.  I recommend following up on the gdb mailing list:

http://www.gnu.org/software/gdb/mailing-lists/

The gdb devs are normally pretty quick to respond.

[ollydbg]

@ironhead:
Thanks, I posted a message in gdb maillist, also a bug report in the GDB Bugzilla.

[ollydbg]

@iron

Today, I found that the time delay problem may due to the Compiler conflict. I used to use TDM-GCC 4.4.1 SIJI version.

Today, I downloaded the GCC 4.4.3 compiler from Loaden's google code:
http://code.google.com/p/qp-gcc

Then, I built wxWidgets library and Codeblocks_SVN using GCC 4.4.3, and try to debug my own "parserTest" project.

Unluckily, I encountered the problem like:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

Both the official mingw gdb 7.0.1 and 7.0.50 get the same error.

Luckily, I found that I can debug the "parserTest" project by gdb.exe built from the latest gdb snapshot like: current/gdb-7.1.50.20100223
Also, it showed the wxString's value quickly, and there's no time lag.

So, if someone meet these same problem as me, I can upload the self built gdb.exe.

Edit
The self-build GDB.exe still has some problems...., and the CLI response time is still a bit slower then the official 7.0.1

[ollydbg]

@ironhead

I have another question:
I build the gdb in a very simple steps:
1, download the GDB tarball from the sourceware ftp
2, (I have MSYS and MinGW installed), I just swith to the GDBXXXX.XXX folder in MSYS command line
3,  entering this command: configure
4,  entering this command: make

So, my question is: it seems the previous version of gdb your build(offical mingw 7.0.1) was depend on the libexpat library. So, do I need to enable the expat library option?, if Yes, How can I build gdb depend on libexpat? thanks very much!

[ironhead]

So, my question is: it seems the previous version of gdb your build(offical mingw 7.0.1) was depend on the libexpat library. So, do I need to enable the expat library option?, if Yes, How can I build gdb depend on libexpat? thanks very much!

Yes, expat is required in order to debug DLLs (amongst other things).  In order to build a gdb that uses expat, you would need to build expat itself (http://expat.sourceforge.net/) and place the headers / libraries somewhere that your compiler can find them.

The expat I use is available on the MinGW project page, but since you are using a different GCC, you will need to build it yourself.  Thankfully the build process is pretty simple, just configure / make.

If you run in to any snags, let me know and I'll do my best to help you out.

[ollydbg]

I find two place I can download the expat.

one is here, from mingw
http://sourceforge.net/projects/mingw/files/MinGW%20expat/expat-2.0.1-1/expat-2.0.1-1-mingw32-src.tar.gz/download

the other is here, from expat official site
http://sourceforge.net/projects/expat/files/expat/2.0.1/expat-2.0.1.tar.gz/download

Did I need to do this:
1, download expat
2, build expat, then it generate a static library like: expat.a
3, then I copy the expat.a to the mingw library folder, and I copy the expat's header files to mingw's include header folders.
4, Then, I build the gdb

right?

[ironhead]

I find two place I can download the expat.

one is here, from mingw
http://sourceforge.net/projects/mingw/files/MinGW%20expat/expat-2.0.1-1/expat-2.0.1-1-mingw32-src.tar.gz/download

the other is here, from expat official site
http://sourceforge.net/projects/expat/files/expat/2.0.1/expat-2.0.1.tar.gz/download

You can use either.  The MinGW sources are the same as the official sources, just renamed.

Did I need to do this:
1, download expat
2, build expat, then it generate a static library like: expat.a
3, then I copy the expat.a to the mingw library folder, and I copy the expat's header files to mingw's include header folders.
4, Then, I build the gdb

right?

Correct.  You can statically link or dynamically against expat.  You can also add '-L<path to expat> -I<path to expat>' to your CFLAGS when compiling gdb.

[ollydbg]

Thanks ironhead.

now, I have successfully build the expat library.

I use this command, suppose I would like to install to C:\ccc, in MSYS, in the expat source root

Code Select Expand


./configure -prefix=/c/ccc --enable-shared  [enter]
...
make[enter]

make install [enter]



Now, I have both dlls and headers and libraries in the C:\ccc

then I copy these files to MinGW, so, now, GCC can use these libraries.

Now, I use these command to configure GDB, suppose I'm in GDB source folder:

Code Select Expand


configure -prefix=/c/ddd -enable-shared [enter]
...
make[enter]

make install [enter]


I'm now building gdb.exe now. Am I right??? thanks.

I would like dynamiclly link to the utilitbins and expat-1.dll as you release 7.0.1. Thanks.

[ollydbg]

I have successfully built the gdb.exe from snapshot of gdb-7.1.50.20100226, but when I'm checking it's dependency, it is *not* depend on the expat-1.dll. As a result, I can't debug CodeCompletion plugin, when I'm setting a breakpoint in the DLL source, the program didn't stopped at that point.

As I found from other site, it seems the expat library is necessary to debug Windows DLL files.

So, my question is:　How to configure the GDB to let it depend on the expat.dll?

Edit:

Code Select Expand

You can also add '-L<path to expat> -I<path to expat>' to your CFLAGS when compiling gdb.
Since I have already copy the generated lib,headers to MinGW folder, do I still set the library path and include path?

I found in here: http://sourceware.org/ml/gdb/2010-01/msg00189.html
What does "-static" used for??

Edit2
In this page http://sourceware.org/gdb/current/onlinedocs/gdb/Requirements.html
Do I need add

Code Select Expand

--with-libexpat
??

[ollydbg]

Oh, I found that I used to do the configure in the root folder(which is totally wrong!!!.....), which is in

C:\gdb-7.1.50.20100226

But for correctly configuration, I need to "cd" to

C:\gdb-7.1.50.20100226\gdb

then ,run

Code Select Expand

./configure --with-expat

in this folder...