Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: ollydbg on October 08, 2009, 08:21:52 am

Title: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on October 08, 2009, 08:21:52 am
Steps to build  gdb under MinGW+MSYS can be seen in the wiki: build_gdb_msys_en (http://code.google.com/p/qp-gcc/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 (http://code.google.com/p/qp-gcc/wiki/GDB)

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 (http://sourceforge.net/projects/gdbmingw/files/gdb2016-01-30.zip/download) and the patches are gdb2016-01-30patches.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2016-01-30patches.zip/download), 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 (https://sourceware.org/bugzilla/show_bug.cgi?id=17659). And the binary is build with G++ compiler. As you know, GDB is migrating to C++.

2014-05-23
gdb2014-05-23.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2014-05-23.zip/download) with patches against GDB GIT HEAD (http://sourceforge.net/projects/gdbmingw/files/gdb2014-05-23patches.zip/download) 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 (https://sourceware.org/bugzilla/show_bug.cgi?id=15806).
2014-01-14
A new release with binary achieve gdb2014-01-14.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2014-01-14.zip/download) and patches against gdb git head gdb2014-01-14patches.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2014-01-14patches.zip/download). 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 (https://sourceware.org/bugzilla/show_bug.cgi?id=12127#c6).
2013-10-09
New release for GDB, the binary achieve is in gdb2013-10-09.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2013-10-09.zip/download), the patches against GDB cvs 2013-10-04 is in gdb2013-10-09patches.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2013-10-09patches.zip/download), 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) (http://forums.codeblocks.org/index.php/topic,18403.0.html), 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 (http://sourceforge.net/projects/gdbmingw/), and the binary achieve is: gdb2013-06-08.7z (http://sourceforge.net/projects/gdbmingw/files/gdb2013-06-08.7z/download) and the patch is gdb2013-06-08.7z (http://sourceforge.net/projects/gdbmingw/files/gdb2013-06-08.7z/download). 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 (http://sourceware.org/bugzilla/show_bug.cgi?id=12127), 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). (http://sourceware.org/bugzilla/show_bug.cgi?id=15412).  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.zip (http://code.google.com/p/qp-gcc/downloads/detail?name=gdb2013-02-04.zip&can=2&q=)with patch gdb2013-02-04.patch (http://code.google.com/p/qp-gcc/downloads/detail?name=gdb2013-02-04.patch&can=2&q=), 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 (http://qp-gcc.googlecode.com/files/gdb2012-12-15.zip) using the patch 2012-12-15.patch (http://qp-gcc.googlecode.com/files/2012-12-15.patch)

2012-08-19
gdb2012-08-17.zip (http://code.google.com/p/qp-gcc/downloads/detail?name=gdb2012-08-17.zip&can=2&q=) build using the patch 2012-08-17.patch (http://code.google.com/p/qp-gcc/downloads/detail?name=2012-08-17.patch&can=2&q=) against gdb cvs head.

2012-05-22
gdb2012-05-22 (http://qp-gcc.googlecode.com/files/gdb2012-05-22.zip)now build from xunxun's mingw gcc 32bit 4.6.3 release.
Here is the total patch file patch against gdb cvs (http://qp-gcc.googlecode.com/files/2012-05-22.patch).
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 (http://sourceware.org/ml/gdb-patches/2012-04/msg00106.html) for more details and other options.


2012-02-16
gdb2012-02-16.7z (http://qp-gcc.googlecode.com/files/gdb2012-02-16.7z) now build from xunxun's gcc 4.6.3 release (http://pcxprj.googlecode.com/files/MinGW64CRT_gcc4.6.3.20120221_sse2static_win32.7z).
The total patch file against vanilla gdb cvs(I use gdb's read only git clone) can be found in: gdb2012-02-16.patch (http://qp-gcc.googlecode.com/files/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 (http://sourceware.org/ml/gdb-patches/2011-12/msg00100.html) does not fully solve the problem: show full paths on backtrace (http://forums.codeblocks.org/index.php/topic,14792.msg99575.html#msg99575).

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 (http://forums.codeblocks.org/index.php/topic,14792.msg99575.html#msg99575).


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 (http://qp-gcc.googlecode.com/files/gdb2012-01-19.7z), it is gdb's latest cvs version with my patch (http://qp-gcc.googlecode.com/files/gdb2012-01-19.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 (http://sourceware.org/ml/gdb-patches/2012-01/msg00676.html) 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 (http://qp-gcc.googlecode.com/files/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 (http://sourceware.org/ml/gdb-patches/2011-11/msg00141.html) and Re: configure file to debug codecompletion plugin (http://forums.codeblocks.org/index.php/topic,12951.msg104087.html#msg104087)

Watchpoint can be used in both gdb.exe and gdbserver.exe, see: brobecke - src/gdb/gdbserver ChangeLog win32-i386-low.c (http://sourceware.org/ml/gdb-cvs/2011-11/msg00039.html)

The total diff file to the gdb cvs head source can be found in: gdb2011-11-08cvs.diff (http://qp-gcc.googlecode.com/files/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 (http://code.google.com/p/qp-gcc/downloads/detail?name=gdb2011-10-09cvs.zip&can=2&q=), 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 (http://forums.codeblocks.org/index.php/topic,15104.msg101072.html#msg101072), I have hack the gdb's data search directory. The full patch was gdb2011-08-08.patch (http://code.google.com/p/qp-gcc/downloads/detail?name=gdb2011-08-08.patch&can=2&q=), 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:
Quote
>>>>>>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 (http://code.google.com/p/qp-gcc/downloads/detail?name=GDB2011-08-10cvs.7z&can=2&q=).

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 (http://forums.codeblocks.org/index.php/topic,14792.msg99575.html#msg99575)
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 (http://qp-gcc.googlecode.com/files/GDB7.3.50.20110804-cvs.7z), Have Fun!!!
Note: please pay attention to this issue when using gdb under Codeblocks:question about exit the debugee when debugging (http://forums.codeblocks.org/index.php/topic,15074.msg100825.html#msg100825).

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 (http://qp-gcc.googlecode.com/files/gdb-7.3.50.20110604.7z)

2011-04-02
new version: gdb-7.2.50.20110401.7z (http://qp-gcc.googlecode.com/files/gdb-7.2.50.20110401.7z)

2011-01-10
build a new gdb cvs version. see gdb7.2.50.20110110-cvs.7z (http://qp-gcc.googlecode.com/files/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 (http://code.google.com/p/qp-gcc/wiki/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 (http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=zh-CN&tl=en&u=http%3A%2F%2Fcode.google.com%2Fp%2Fqp-gcc%2Fwiki%2Fbuild_gdb_msys_cn&act=url).

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 (http://qp-gcc.googlecode.com/files/gdb-7.2.50.20101213.7z) You need to have python 2.7.1 installed on your system.

I'm really appreciate to xunxun1982 (http://forums.codeblocks.org/index.php?action=profile;u=12871)'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 (http://qp-gcc.googlecode.com/files/gdb-7.2.7z)
Thanks loaden for the build. for How to use GDB with python under Codeblocks, see:
Use GDB python under Codeblocks (http://code.google.com/p/qp-gcc/wiki/GDB)

2010-07-09
The new gdb file has uploaded to gdb-7.2.50.20100708-cvs.7z (http://qp-gcc.googlecode.com/files/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 (http://forums.codeblocks.org/index.php/topic,11301.msg86240.html#msg86240)

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 (http://ftp://sourceware.org/pub/gdb/snapshots/current/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 (http://qp-gcc.googlecode.com/files/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 (http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.1/gdb-7.0.1-mingw32-bin.tar.gz/download), 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 (http://sourceforge.net/projects/mingw/files/MinGW%20expat/expat-2.0.1-1/libexpat-2.0.1-1-mingw32-dll-1.tar.gz/download)

Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 08:35:44 am
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. :D

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:

 :(
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: Jenna on October 08, 2009, 09:14:17 am
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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: oBFusCATed on October 08, 2009, 09:48:52 am
Will test on arch linux today, hope it works
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: Jenna on October 08, 2009, 10:50:59 am
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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 01:21:39 pm
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]
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: mariocup on October 08, 2009, 01:31:50 pm
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


Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 01:41:18 pm
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!
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 01:43:49 pm
In the MinGW maillist. someone said:

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


Title: Re: [OT] MinGW GDB 7.0 is released
Post by: killerbot on October 08, 2009, 01:50:58 pm
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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 02:02:55 pm
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.

 :(

Title: Re: [OT] MinGW GDB 7.0 is released
Post by: vix on October 08, 2009, 02:27:29 pm
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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 02:43:04 pm
@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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: MortenMacFly on October 08, 2009, 02:51:04 pm
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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: vix on October 08, 2009, 02:59:38 pm
@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.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 03:22:59 pm
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.

Thanks for the hint. I have totally uninstall and remove the TDM.

Then, I just reinstall TDM , and upzip the GDB7.0 package(Note, GDB7.0 has four folders, so, I just let the GDB7.0's file overwrite the TDM's)

But, I still get the same error, things like:

Code
>>>>>>cb_gdb:
> break "F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:588"
No source file named F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp.
Breakpoint 2 ("F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:588) pending.
>>>>>>cb_gdb:
> run
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: oBFusCATed on October 08, 2009, 03:47:56 pm
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.

ollydbg: Have your read the line in bold?
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 03:54:28 pm
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.

ollydbg: Have your read the line in bold?

Yes, I have read that, I also had tested that method.
I just set a breakpoint in the main function, which is in

F:\cb_svn\src\tools\ConsoleRunner\main.cpp

But it still can't stops there. :(

Code

Working dir : F:\cb_svn\src\
> set prompt >>>>>>cb_gdb:
Reading symbols from F:\cb_svn\src/devel/codeblocks.exe...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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 disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source F:\debugger_branch\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> cd devel
>>>>>>cb_gdb:
> directory F:/cb_svn/src/
>>>>>>cb_gdb:
> set args --debug-log --no-check-associations -ns -nd
>>>>>>cb_gdb:
> break "F:/cb_svn/src/tools/ConsoleRunner/main.cpp:84"
No source file named F:/cb_svn/src/tools/ConsoleRunner/main.cpp.
Breakpoint 2 ("F:/cb_svn/src/tools/ConsoleRunner/main.cpp:84) pending.
>>>>>>cb_gdb:
> run
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: oBFusCATed on October 08, 2009, 04:48:34 pm
main should be in src/src/main.cpp not in the console runner :)
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: MortenMacFly on October 08, 2009, 04:59:51 pm
F:\cb_svn\src\tools\ConsoleRunner\main.cpp
Harhar... :lol:

Well... try a BP src/src/main.cpp e.g. in the CreateIDE() method.

The main.cpp you pointed to will not work, obviously, as this is only the console_runner executable, not C::B itself. ;-)
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 08, 2009, 05:01:51 pm
main should be in src/src/main.cpp not in the console runner :)
My god... Big mistake...
Thanks, I will try this tomorrow, it's time to go to bed now. :wink:

Edit


But for gdb.exe 6.8.3, I don't need to  firstly set a breakpoint in the main(), I can directly set a breakpoint any where(for example tokenizer.cpp). :D
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: MortenMacFly on October 08, 2009, 05:18:28 pm
But for gdb.exe 6.8.3, I don't need to  firstly set a breakpoint in the main(), I can directly set a breakpoint any where(for example tokenizer.cpp). :D
The same applied for GDB7. "main" was just an example. ;-) Good night! :P
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 09, 2009, 02:47:17 am
@morten

Setting breakpoing at src\src\main.cpp, CreateIDE() works.
When the breakpoint above hitted. I still can't set breakpoint in tokenizer.cpp DoGetToken(). :(

Here is the log:

Code
GNU gdb (GDB) 7.0
Copyright (C) 2009 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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 disassembly-flavor intel
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source D:\Program Files\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> cd devel
>>>>>>cb_gdb:
> directory F:/cb_svn/src/
>>>>>>cb_gdb:
> set args --debug-log --no-check-associations -ns -nd
>>>>>>cb_gdb:
> break "F:/cb_svn/src/src/main.cpp:631"
Breakpoint 2 at 0x429658: file F:\cb_svn\src\src\main.cpp, line 631.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
gdb: kernel event for pid=3348 tid=3508 code=CREATE_PROCESS_DEBUG_EVENT)
[New Thread 3348.0xdb4]
.......
ContinueDebugEvent (cpid=3348, ctid=3496, DBG_CONTINUE);
gdb: kernel event for pid=3348 tid=3508 code=EXCEPTION_DEBUG_EVENT)
Breakpoint 2, MainFrame::CreateIDE (this=0x3718af0) at F:\cb_svn\src\src\main.cpp:631
F:\cb_svn\src\src\main.cpp:631:32181:beg:0x429658
Current language:  auto
The current source language is "auto; currently c++".
>>>>>>cb_gdb:
> info locals
leftW = 200
clientsize = {
  x = 65055748,
  y = 62728
}
>>>>>>cb_gdb:
> info args
this = 0x3718af0
>>>>>>cb_gdb:
> whatis actual
No symbol "actual" in current context.
>>>>>>cb_gdb:
> output actual
No symbol "actual" in current context.
>>>>>>cb_gdb:
> whatis cashed_results_count
No symbol "cashed_results_count" in current context.
>>>>>>cb_gdb:
> output cashed_results_count
No symbol "cashed_results_count" in current context.
>>>>>>cb_gdb:
> whatis line
No symbol "line" in current context.
>>>>>>cb_gdb:
> output line
No symbol "line" in current context.
>>>>>>cb_gdb:
> whatis m_TokenIndex
No symbol "m_TokenIndex" in current context.
>>>>>>cb_gdb:
> output m_TokenIndex
No symbol "m_TokenIndex" in current context.
>>>>>>cb_gdb:
> whatis next
No symbol "next" in current context.
>>>>>>cb_gdb:
> output next
No symbol "next" in current context.
>>>>>>cb_gdb:
> whatis res
No symbol "res" in current context.
>>>>>>cb_gdb:
> output res
No symbol "res" in current context.
>>>>>>cb_gdb:
> whatis startAt
No symbol "startAt" in current context.
>>>>>>cb_gdb:
> output startAt
No symbol "startAt" in current context.
>>>>>>cb_gdb:
> bt 30
#0  MainFrame::CreateIDE (this=0x3718af0) at F:\cb_svn\src\src\main.cpp:631
#1  0x0042736d in MainFrame (this=0x3718af0, parent=0x0) at F:\cb_svn\src\src\main.cpp:511
#2  0x004026e3 in CodeBlocksApp::InitFrame (this=0x367bc08) at F:\cb_svn\src\src\app.cpp:401
#3  0x00404c57 in CodeBlocksApp::OnInit (this=0x367bc08) at F:\cb_svn\src\src\app.cpp:625
#4  0x00469b30 in wxAppConsole::CallOnInit (this=0x367bc08) at D:/wxWidgets-2.8.10/include/wx/app.h:76
#5  0x6273bff1 in ?? ()
#6  0x0367bc08 in ?? ()
#7  0x0367b870 in ?? ()
#8  0x40000060 in ?? ()
#9  0x77c2c3ce in ?? ()
#10 0x00460044 in wxWindow::Thaw() ()
#11 0x7ffdfc00 in ?? ()
#12 0x00261f03 in ?? ()
#13 0x0023fe6c in ?? ()
warning: (Internal error: pc 0x261f02 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x261f02 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x261f02 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x261f02 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x261f02 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe6b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe6b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe6b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe6b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe6b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fecb in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fecb in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fecb in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fecb in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fecb in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2ffff in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2ffff in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2ffff in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2ffff in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2ffff in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe67 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe67 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe67 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe67 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x23fe67 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
#14 0x00000003 in ?? () at F:\cb_svn\src\src\appglobals.cpp:57
#15 0x627a5977 in ?? ()
#16 0x0023fecc in ?? ()
#17 0x0367b870 in ?? ()
#18 0x0367afb0 in ?? ()
#19 0x00030000 in ?? ()
#20 0x0367afa8 in ?? ()
#21 0x0023fe68 in ?? ()
#22 0x7c96e52f in ?? ()
#23 0x0367b870 in ?? ()
#24 0x0367b870 in ?? ()
#25 0x00000005 in ?? () at d:/mingw/bin/../lib/gcc/mingw32/4.4.0/include/c++/ext/new_allocator.h:73
#26 0x00401d58 in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0, lpCmdLine=0x261f03 "--debug-log --no-check-associations -ns -nd", nCmdShow=10) at F:\cb_svn\src\src\app.cpp:256
#27 0x00465e48 in main ()
>>>>>>cb_gdb:
> whatis MainFrame
Type MainFrame has no component named MainFrame.
>>>>>>cb_gdb:
> output MainFrame
cannot resolve overloaded method `MainFrame': no arguments supplied
>>>>>>cb_gdb:
> output MainFrame
cannot resolve overloaded method `MainFrame': no arguments supplied
>>>>>>cb_gdb:
> output MainFrame
cannot resolve overloaded method `MainFrame': no arguments supplied
>>>>>>cb_gdb:
> break "F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:588"
No source file named F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp.
Breakpoint 3 ("F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:588) pending.
>>>>>>cb_gdb:
> cont

Quite strange, breakpoint on some source file works, but others don't.

Code
>>>>>>cb_gdb:
> break "F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:588"
No source file named F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp.
Breakpoint 3 ("F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:588) pending.

It seems there is still some bug in TDM-MinGW 4.4 or GDB.exe7.0   :(
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: theOcelot on October 09, 2009, 07:30:13 pm
It's not working for me. I've always had trouble with hitting breakpoints in headers. Here's a few more datapoints to work with:

I'm on Windows Vista, the official MinGW G++ 4.4.0, and CB 8.02. I started a fresh, C++, CB console project, and added the following file, named "tester1.h":
Code
#ifndef TESTER1_H
#define TESTER1_H

#include <iostream>

inline void function(){
    std::cout << "in function()" << std::endl;
}

struct Foo{
    Foo(){
        std::cout << "constructing Foo" << std::endl;
    }
    void bar(){
        std::cout << "Foo::bar" << std::endl;
    }
};

#endif

Then in main .cpp:
Code
int main()
{
    cout << "Hello world!" << endl;
    Foo foo;
    function();
    foo.bar();
    return 0;
}

I set breakpoints on all the output lines in tester1.h, and on the return 0. Only the latter was hit, with either GDB 6.8 or 7.0. Same results when I named the header tester.h, in case the number in the filename was screwing things up. There path to my project is C:\Users\Fleenor\Projects\DebugTest, no spaces or anything irregular. Mingw is C:\MinGW.

Here is my debug log with GDB 7.0, tester1.h:
Code
PATH=.;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\hp\bin\Python;C:\MinGW\bin;C:\Program Files\Subversion\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\TortoiseSVN\bin
Command-line: C:\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/DebugTest.exe
Working dir : C:\Users\Fleenor\Projects\DebugTest\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\Users\Fleenor\Projects\DebugTest/bin/Debug/DebugTest.exe...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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:
> directory C:/Users/Fleenor/Projects/DebugTest/
>>>>>>cb_gdb:
> break "C:/Users/Fleenor/Projects/DebugTest/main.cpp:12"
Breakpoint 1 at 0x4013ef: file C:\Users\Fleenor\Projects\DebugTest\main.cpp, line 12.
>>>>>>cb_gdb:
> break "C:/Users/Fleenor/Projects/DebugTest/tester1.h:15"
No source file named C:/Users/Fleenor/Projects/DebugTest/tester1.h.
Breakpoint 2 ("C:/Users/Fleenor/Projects/DebugTest/tester1.h:15) pending.
>>>>>>cb_gdb:
> break "C:/Users/Fleenor/Projects/DebugTest/tester1.h:12"
No source file named C:/Users/Fleenor/Projects/DebugTest/tester1.h.
Breakpoint 3 ("C:/Users/Fleenor/Projects/DebugTest/tester1.h:12) pending.
>>>>>>cb_gdb:
> break "C:/Users/Fleenor/Projects/DebugTest/tester1.h:7"
No source file named C:/Users/Fleenor/Projects/DebugTest/tester1.h.
Breakpoint 4 ("C:/Users/Fleenor/Projects/DebugTest/tester1.h:7) pending.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
gdb: kernel event for pid=2840 tid=3476 code=CREATE_PROCESS_DEBUG_EVENT)
[New Thread 2840.0xd94]
gdb: kernel event for pid=2840 tid=3476 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\Windows\system32\ntdll.dll" at 0x76e30000.
gdb: kernel event for pid=2840 tid=3476 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\Windows\system32\kernel32.dll" at 0x76bb0000.
gdb: kernel event for pid=2840 tid=3476 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\Windows\system32\msvcrt.dll" at 0x75720000.
gdb: kernel event for pid=2840 tid=3476 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\MinGW\bin\libgcc_s_dw2-1.dll" at 0x6e940000.
gdb: kernel event for pid=2840 tid=3476 code=EXCEPTION_DEBUG_EVENT)
warning: Can not parse XML library list; XML support was disabled at compile time
gdb: kernel event for pid=2840 tid=3476 code=EXCEPTION_DEBUG_EVENT)
Breakpoint 1, main () at C:\Users\Fleenor\Projects\DebugTest\main.cpp:12
C:\Users\Fleenor\Projects\DebugTest\main.cpp:12:168:beg:0x4013ef
>>>>>>cb_gdb:
> info locals
foo = {<No data fields>}
>>>>>>cb_gdb:
> info args
No arguments.
>>>>>>cb_gdb:
> bt 30
#0  main () at C:\Users\Fleenor\Projects\DebugTest\main.cpp:12
>>>>>>cb_gdb:
> quit
gdb: windows_close, inferior_ptid=2840

The interesting part of course is where it still says "No source file named C:/Users/Fleenor/Projects/DebugTest/tester1.h." I wonder if it could be something to do with the different slash types, but it seems like that would have been fixed a long time ago.

I don't really want to do anything to further confuse my installation, but would TDM help me? Is the only way to know to try? I'll attach my project in 7z format, if anyone wants to see if they can reproduce my behavior, or show non-reproducibility on their system.

[attachment deleted by admin]
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: oBFusCATed on October 09, 2009, 07:54:10 pm
Can you try a nightly build?
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: theOcelot on October 09, 2009, 09:35:49 pm
Can you try a nightly build?
Who, me? Of CB? Sure, I guess. Do you mean get it from SVN? I can't find a binary download link for the nightlies anymore. I also don't know for sure how the build will work with my wxWidgets.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: oBFusCATed on October 09, 2009, 09:43:30 pm
theOcelot: yes you  :lol:,  binary nightly build (not hyper new, but uber new relative to the 8.02 release) can be found in the nightly subforum on this site  :lol:
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 10, 2009, 03:26:03 am
@theOcelot

I test your code.

Q:Is breakpoint in a header file works?

A: Win XP TDM-MinGW 4.4.1  GDB 6.8.3 works

A: Win XP TDM-MinGW 4.4.1  GDB 7.0    works


By the way:
Does other guys try setting a breakpoint in a C::B's plugin source, like plugins\codecompletion\parser\tokenizer.cpp. It seems the breakpoints don't work there. The problem is quite the same:

Code
>>>>>>cb_gdb:
> break "F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:591"
No source file named F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp.
Breakpoint 4 ("F:/cb_svn/src/plugins/codecompletion/parser/tokenizer.cpp:591) pending.



Title: Re: [OT] MinGW GDB 7.0 is released
Post by: theOcelot on October 10, 2009, 08:32:37 am
Ha! Victory! I hand-compiled main.cpp into main.o on the command line, using relative paths with forward slashes instead of absolute paths with backslashes, as in Bob Fletcher's bug report (http://"http://sourceforge.net/tracker/index.php?func=detail&aid=2145427&group_id=200665&atid=974439"). Once CB linked it, it worked, and all three header breakpoints were hit.

The nightly build has the same behavior, passing paths using backslashes, so the problem didn't go away when I switched. Maybe it will let me ctrl-shift-F9 to compile just one file without crashing again, in which case it will have been worth it anyway.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 10, 2009, 09:22:41 am
I think I find the reason why I can't debug C::B under GDB 7.0 (Win XP TDM-MinGW 4.4.1 )

Here is my steps:
1, clear all the breakpoints.
2, I start debugging.
3, the debuggee started
4, but I fond that GDB.exe hungs, because I can't manually send the debug command in the "debug" panel. There's no response after I hit enter button.

 :(

Any ideas?

Edit
I just do another test:

1, clear all the breakpoints.
2, I start debugging.
3, the debuggee started
4, I click on the "stop debugger" button, but it seems the debugger can't be paused.

Here is the log:

Code
Debugger name and version: GNU gdb (GDB) 7.0
Trying to pause the running process...

So, I know why I can't set breakpoint when debugging, you can see the code below:

Code
bool DebuggerGDB::AddBreakpoint(const wxString& file, int line)
{
    const bool debuggerIsRunning = !IsStopped();
    if (debuggerIsRunning)
    {
        Break();
    }
    m_State.AddBreakpoint(file, line, false);
    if (m_pBreakpointsWindow)
    {
        m_pBreakpointsWindow->Refresh();
    }
    if (debuggerIsRunning)
    {
        Continue();
    }
    return true;
} // end of AddBreakpoint

But it seems the "Break();"  function can not be executed correctly( gdb is still running or gdb hangs ), then certainly I can't set the following breakpoints.


Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ironhead on October 10, 2009, 01:47:58 pm
How is C::B attempting to 'pause' gdb.exe?
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 10, 2009, 01:51:56 pm
How is C::B attempting to 'pause' gdb.exe?
Read the source code of the Break() function. You will see it.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 10, 2009, 02:27:44 pm
In the code:

Code
void DebuggerGDB::Break()
{
    // m_Process is PipedProcess I/O; m_Pid is debugger pid
    if (m_pProcess && m_Pid && !IsStopped())
    {
        long pid = m_State.GetDriver()->GetChildPID();
        if (pid <= 0)
            pid = m_Pid; // try poking gdb directly
    #ifndef __WXMSW__
        // non-windows gdb can interrupt the running process. yay!
        if (pid <= 0) // look out for the "fake" PIDs (killall)
            cbMessageBox(_("Unable to stop the debug process!"), _("Error"), wxOK | wxICON_WARNING);
        else
            wxKill(pid, wxSIGINT);
    #else
        // windows gdb can interrupt the running process too. yay!
        bool done = false;
        if (DebugBreakProcessFunc && pid > 0)
        {
            Log(_("Trying to pause the running process..."));
            HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, (DWORD)pid);
            if (proc)
            {
                DebugBreakProcessFunc(proc); // yay!
                CloseHandle(proc);
                done = true;
            }
            else
                Log(_("Failed."));
        }
    #endif
        // Notify debugger plugins for end of debug session
        PluginManager *plm = Manager::Get()->GetPluginManager();
        CodeBlocksEvent evt(cbEVT_DEBUGGER_PAUSED);
        plm->NotifyPlugins(evt);
}
}

The main task is call the DebugBreakProcessFunc function. Which is defined by :

Code
    kernelLib = LoadLibrary(TEXT("kernel32.dll"));
    if (kernelLib)
        DebugBreakProcessFunc = (DebugBreakProcessApiCall)GetProcAddress(kernelLib, "DebugBreakProcess");
    #endif
}

Also, you can find a stand alone program in this page:

http://cygwin.com/ml/cygwin/2006-06/msg00321.html

or

http://forums.codeblocks.org/index.php?topic=8577.0

or

http://www.nabble.com/GDB-Ctrl-C-Break-td1782635.html

or

http://forums.codeblocks.org/index.php/topic,7964.msg59677.html#msg59677
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ironhead on October 10, 2009, 04:36:04 pm
As posted in this message:

http://forums.codeblocks.org/index.php/topic,7964.msg61123.html#msg61123

Wouldn't sending a:

Code
mi interrupt

Make the most sense, since it works cross platform and uses the GDB internals as opposed to relying on a win32api call that only exists in XP and above?
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 10, 2009, 05:09:03 pm
As posted in this message:

http://forums.codeblocks.org/index.php/topic,7964.msg61123.html#msg61123

Wouldn't sending a:

Code
mi interrupt

Make the most sense, since it works cross platform and uses the GDB internals as opposed to relying on a win32api call that only exists in XP and above?


I personally think this command make no sense, because when the debuggee is running, GDB.exe  can't accept any command.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 11, 2009, 03:40:42 am
Hi, all, I just find some more issue of gdb.exe 7.0, it seems that gdb.exe 7.0 can't set breakpoint in a DLL's source file, but gdb.exe 6.8.3 can.

Here is the test project, it contains two target, one is a exe, and one is a dll, then, the exe will call a function in the dll.

You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.




[attachment deleted by admin]
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: nanyu on October 11, 2009, 06:04:26 am

You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.


And I found the program didn't step into the function where from a DLL project when I press Shift+F7 ...
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 11, 2009, 06:14:38 am

You can set breakpoints in both exe and dll, but for gdb.exe 7.0, only breakpoints in exe file can be reached.


And I found the program didn't step into the function where from a DLL project when I press Shift+F7 ...

So, this means gdb 7.0 treats dll file badly. :(
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: theOcelot on October 11, 2009, 06:40:59 am
Switching to TDM g++ on one of my installations seems to have fixed it for good. I'll see about switching my main comp to TDM, if they don't put this fix in the official MinGW pretty soon.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: Jenna on October 11, 2009, 11:01:59 pm
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.

The cause for the flood of (visible) ContinueDebugEvent's is that the gdb startline has changed from GNU gdb x.x.x to GNU gdb (GDB) x.x.x.
The additional (GDB) breaks our code to determine the gdb major- and minor-version and that breaks the code that determines the child-pid's of gdb.
After fetching the child-pid we no longer parse lines that start with ContinueDebugEvent.

I think we could use a regex here to filter out the version number, to avoid such problems inth future.

here is patch that can do that:
Code
Index: gdb_driver.cpp
===================================================================
--- gdb_driver.cpp (Revision 5861)
+++ gdb_driver.cpp (Arbeitskopie)
@@ -861,7 +861,13 @@
             // it's the gdb banner. Just display the version and "eat" the rest
             m_pDBG->Log(_("Debugger name and version: ") + lines[i]);
             // keep major and minor version numbers handy
-            wxString major = lines[i].Right(lines[i].Length() - 8);
+            wxRegEx re(_T("([0-9.]+)"));
+            if (!re.Matches(lines[i]))
+            {
+                m_pDBG->Log(_T("Unable to determine the version of gdb"));
+                break;
+            }
+            wxString major = re.GetMatch(lines[i],0);
             wxString minor = major;
             major = major.BeforeFirst(_T('.')); // 6.3.2 -> 6
             minor = minor.AfterFirst(_T('.')); // 6.3.2 -> 3.2

It does not fix the main problem (can not set breakpoints in some files and libs) of course, but that appears to be a gdb-issue.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 12, 2009, 01:25:30 am
Continue the "breakpoint" problem.
From the mingw user mail list, I found that post below mine

Quote
>> B: I found that the GDB.exe 7.0 *can't* set breakpoints on an DLL's
>> >> source file.
>> >>
>> >> For example I have A.cpp->A.exe and B.cpp->B.dll.
>> >>
>> >> Then A.exe depend on the B.dll.
>> >>
>> >> When I debug A.exe, I *can* set breakpoints in A.cpp, but I *can't* set
>> >> breakpoints in B.cpp.
>> >>
>> >> In GDB.exe 6.8.3, breakpoints can set in both A.cpp and B.cpp.
>> >>
>> >> I have added the test code in C::B forum post:
>> >> http://forums.codeblocks.org/index.php/topic,11301.msg77123.html#msg77123
> >
> > I'll take a look at this in a couple of days, since I'm swamped with
> > other stuff at the moment.  I'll let you know how I make out...

I managed to find a little time to test debugging a DLL and I was able
to do so with GDB.  Here's the steps I ran:

1.  Compile both the 'exe' and 'dll' with debug symbols
2.  Run 'gdb'
3.  From the (gdb) prompt type 'file [library name].dll'
4.  From the (gdb) prompt type 'break [library source file].cpp:[line number]'
5.  From the (gdb) prompt type 'exec-file [executable name].exe'
6.  From the (gdb) prompt type 'run'

As expected, gdb stopped at the line number in the library source file.

So from a GDB standpoint, it is behaving as expected and it can set
breakpoints on DLLs and actually hit them.  I'll grab the latest C::B
nightly Tuesday (unfortunately I won't have the time tomorrow to test
it) and see how it goes about debugging a library.

Cheers!

Chris


So, it seems in the now gdb 7.0, we should manually send command 'file [library name].dll' . I think currently, this haven't done in the C::B's debugger plugin.

Title: Re: [OT] MinGW GDB 7.0 is released
Post by: oBFusCATed on October 12, 2009, 01:41:24 am
Yes it is not done and I'm not sure if it can be done easily...
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 12, 2009, 08:30:39 am
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.


hello, the source file was "utils.c" not "util.c"  :D

Also, I have successfully built the gdb.exe under TDM-GCC 4.4.1 and MSYS system. :D
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 12, 2009, 11:39:38 am
I just find more bugs of GDB.

Follow the steps

 Here's the steps I ran:

1.  Compile both the 'exe' and 'dll' with debug symbols
2.  Run 'gdb'
3.  From the (gdb) prompt type 'file [library name].dll'
4.  From the (gdb) prompt type 'break [library source file].cpp:[line number]'
5.  From the (gdb) prompt type 'exec-file [executable name].exe'
6.  From the (gdb) prompt type 'run'


I still can't load the dll file. here is the Debug log:
Code
> file "F:\cb_svn\src\devel\share\CodeBlocks\plugins\codecompletion.dll"
F:cb_svnsrcdevelshareCodeBlockspluginscodecompletion.dll: No such file or directory.
>>>>>>cb_gdb:
> file codecompletion.dll
codecompletion.dll: No such file or directory.
>>>>>>cb_gdb:

 :(





Title: Re: [OT] MinGW GDB 7.0 is released
Post by: nenin on October 12, 2009, 11:47:04 am
You can try like this:
Code
file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 12, 2009, 01:41:16 pm
You can try like this:
Code
file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll


Thanks, but it still doesn't work.

Code
>>>>>>cb_gdb:
> file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll
warning: (Internal error: pc 0x4295cc in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4295cc in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4295cc in read in psymtab, but not in symtab.)
Error in re-setting breakpoint 2: No source file named F:/cb_svn/src/src/main.cpp.
warning: (Internal error: pc 0x4295cc in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4295cc in read in psymtab, but not in symtab.)
>>>>>>cb_gdb:

Note: I have one breakpoint in F:/cb_svn/src/src/main.cpp already.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on October 14, 2009, 07:36:26 am
Hi, all, from the MinGW mail list, the new updated GDB.exe 7.02 is released, and the "setting bp issue on dll" is gone.

Quote
I've uploaded a new GDB 7.0 release with XML parsing enabled via
linking to libexpat.  It's available here:

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

For this release you will need libexpat-2.0.1-1-mingw32-dll-1.tar.gz,
available here:

http://sourceforge.net/projects/mingw/files/MinGW%20expat/expat-2.0.1-1/libexpat-2.0.1-1-mingw32-dll-1.tar.gz/download

As before, please report any issues to the MinGW-users list.

Chris

also:

Quote
I've dug in to this and managed to add a break point in a DLL using
C::B.  I built my DLL with debug symbols and set a breakpoint in the
source for the DLL.  I then selected and executable that calls the DLL
and hit the 'Debug / Continue' button and it hit the DLL breakpoint.

I'm using a self compiled (using the official MinGW GCC 4.4.0) C::B
from svn trunk, GDB 7.0-2 and a DLL and app compiled with the official
MinGW GCC.

Cheers!

Chris

Now, I have confirm that the new gdb.exe 7.02 and TDM GCC 4.4.1 can works perfectly!!!

And if you want to build a C::B that support the new GDB 7.0, you should apply this patch by jens.

http://forums.codeblocks.org/index.php/topic,11301.msg77156.html#msg77156
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ollydbg on October 14, 2009, 08:31:32 am
Another question, can somebody explain that what's these warning means?

Code
> bt 30
#0  Tokenizer::DoGetToken (this=0x5b21a38) at F:\cb_svn\src\plugins\codecompletion\parser\tokenizer.cpp:809
#1  0x65ee7987 in Tokenizer::GetToken (this=0x5b21a38) at F:\cb_svn\src\plugins\codecompletion\parser\tokenizer.cpp:568
warning: (Internal error: pc 0x6279c950 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279c950 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279c950 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279c950 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279c950 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e28a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e28a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e28a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e28a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e28a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e35b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e35b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e35b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e35b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279e35b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279dc92 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279dc92 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279dc92 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279dc92 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x6279dc92 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62701507 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62701507 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62701507 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62701507 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62701507 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62bd7254 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62bd7254 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62bd7254 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62bd7254 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x62bd7254 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x22fb0b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x22fb0b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x22fb0b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x22fb0b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x22fb0b in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2f in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2f in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2f in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2f in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x2f in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x627dbe61 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x627dbe61 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x627dbe61 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x627dbe61 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x627dbe61 in read in psymtab, but not in symtab.)
#2  0x65ed55e7 in ParserThread::HandleIncludes (this=0x5b21a30) at F:\cb_svn\src\plugins\codecompletion\parser\parserthread.cpp:919
#3  0x65ed35e0 in ParserThread::DoParse (this=0x5b21a30) at F:\cb_svn\src\plugins\codecompletion\parser\parserthread.cpp:505
#4  0x65ed2cf1 in ParserThread::Parse (this=0x5b21a30) at F:\cb_svn\src\plugins\codecompletion\parser\parserthread.cpp:369
#5  0x65ece3f8 in Parser::ParseBufferForFunctions (this=0x22f168, buffer=...) at F:\cb_svn\src\plugins\codecompletion\parser\parser.cpp:569
#6  0x65eb0e6d in CodeCompletion::ParseFunctionsAndFillToolbar (this=0x4044ce8, force=false) at F:\cb_svn\src\plugins\codecompletion\codecompletion.cpp:1410
#7  0x65eb026f in CodeCompletion::OnWorkspaceChanged (this=0x4044ce8, event=...) at F:\cb_svn\src\plugins\codecompletion\codecompletion.cpp:1180
#8  0x65ef5794 in cbEventFunctor<CodeCompletion, CodeBlocksEvent>::Call (this=0x599bf60, event=...) at F:/cb_svn/src/include/cbfunctor.h:35
#9  0x00c32f2c in Manager::ProcessEvent (this=0x36e0c58, event=...) at F:\cb_svn\src\sdk\manager.cpp:179
#10 0x00c4eb4a in PluginManager::NotifyPlugins (this=0x4042038, event=...) at F:\cb_svn\src\sdk\pluginmanager.cpp:1466
#11 0x00c80992 in ProjectManager::WorkspaceChanged (this=0x3e76008) at F:\cb_svn\src\sdk\projectmanager.cpp:2630
#12 0x00c81c6e in ProjectManager::EndLoadingProject (this=0x3e76008, project=0x5aebff8) at F:\cb_svn\src\sdk\projectmanager.cpp:2831
#13 0x00c75c93 in ProjectManager::LoadProject (this=0x3e76008, filename=..., activateIt=true) at F:\cb_svn\src\sdk\projectmanager.cpp:857
#14 0x0043284e in MainFrame::DoOpenProject (this=0x37473d8, filename=..., addToHistory=true) at F:\cb_svn\src\src\main.cpp:1610
#15 0x0043231c in MainFrame::OpenGeneric (this=0x37473d8, filename=..., addToHistory=true) at F:\cb_svn\src\src\main.cpp:1559
#16 0x00435e65 in MainFrame::OnStartHereLink (this=0x37473d8, event=...) at F:\cb_svn\src\src\main.cpp:1880
#17 0x6279c951 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
#18 0x6279e28b in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
#19 0x6279e35c in wxEvtHandler::ProcessEvent(wxEvent&) () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
#20 0x6279dc93 in wxEvtHandler::ProcessPendingEvents() () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
#21 0x62701508 in wxAppConsole::ProcessPendingEvents() () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
#22 0x62bd7255 in wxIdleWakeUpModule::MsgHookProc () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
#23 0x7e41ead2 in USER32!EnableMenuItem () from C:\WINDOWS\system32\user32.dll
#24 0x7e41ea7e in USER32!EnableMenuItem () from C:\WINDOWS\system32\user32.dll
#25 0x7e41ebd3 in USER32!CallNextHookEx () from C:\WINDOWS\system32\user32.dll
#26 0x7c90e473 in ntdll!LdrDestroyOutOfProcessImage () from C:\WINDOWS\system32\ntdll.dll
#27 0x0022fb0c in ?? ()
#28 0x00000030 in ?? () at F:/cb_svn/src/include/blockallocated.h:80
#29 0x627dbe62 in wxEventLoop::Dispatch() () from F:\cb_svn\src\devel\wxmsw28u_gcc_custom.dll
>>>>>>cb_gdb:
> delete breakpoints 2
>>>>>>cb_gdb:
> cont

Thanks.
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: oBFusCATed on October 14, 2009, 09:26:56 am
Ollydbg: try asking the gdb devs directly (#gdb at freenode will be the fastest).
This seems to be a gdb problem...
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ollydbg on October 14, 2009, 09:48:07 am
Ollydbg: try asking the gdb devs directly (#gdb at freenode will be the fastest).
This seems to be a gdb problem...
thanks, currently, I just asked in MinGW user mail list, I haven't heard http://freenode.net/ before.. :shock:
So, I will learn to use it then.
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ironhead on October 14, 2009, 06:26:23 pm
Ollydbg: try asking the gdb devs directly (#gdb at freenode will be the fastest).
This seems to be a gdb problem...
thanks, currently, I just asked in MinGW user mail list, I haven't heard http://freenode.net/ before.. :shock:
So, I will learn to use it then.

It's an irc service (irc.freenode.net).  Alternately, perhaps follow-up on the GDB mailing list.  I'll try to recreate the issue later today and follow up accordingly.  When I do a backtrace using using GDB command line I don't see these messages.
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: killerbot on October 14, 2009, 07:28:34 pm
Quote
And if you want to build a C::B that support the new GDB 7.0, you should apply this patch by jens.

http://forums.codeblocks.org/index.php/topic,11301.msg77156.html#msg77156

Applied in trunk.
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ollydbg on October 15, 2009, 02:37:18 am
Ollydbg: try asking the gdb devs directly (#gdb at freenode will be the fastest).
This seems to be a gdb problem...
thanks, currently, I just asked in MinGW user mail list, I haven't heard http://freenode.net/ before.. :shock:
So, I will learn to use it then.

It's an irc service (irc.freenode.net).  Alternately, perhaps follow-up on the GDB mailing list.  I'll try to recreate the issue later today and follow up accordingly.  When I do a backtrace using using GDB command line I don't see these messages.


hello, thanks.
I just test a simple exe and dll project, then I don't see any such warnings.

But these warning is exist when I'm debugging the C::B's plugin dll. :D, so, I'm not sure there is the something wrong with C::B plugin or others. :(
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: olelukoie on October 20, 2009, 04:21:31 pm
hello, thanks.
I just test a simple exe and dll project, then I don't see any such warnings.

But these warning is exist when I'm debugging the C::B's plugin dll. :D, so, I'm not sure there is the something wrong with C::B plugin or others. :(
I see the same warnings with different hex values when debugging Qt4-based app with TDM-GCC+GDB7+Eclipse+CDT+Qt eclipse integration. And I don't see them when I revert back to GDB 6.8 that comes in the TDM's installer. So I think it's not a CB-related problem (at least not CB-specific one).
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ollydbg on October 20, 2009, 04:29:39 pm
hello, thanks.
I just test a simple exe and dll project, then I don't see any such warnings.

But these warning is exist when I'm debugging the C::B's plugin dll. :D, so, I'm not sure there is the something wrong with C::B plugin or others. :(
I see the same warnings with different hex values when debugging Qt4-based app with TDM-GCC+GDB7+Eclipse+CDT+Qt eclipse integration. And I don't see them when I revert back to GDB 6.8 that comes in the TDM's installer. So I think it's not a CB-related problem (at least not CB-specific one).
Agreed, but I have no idea how to solve this problem, we need a GDB developer's help. :D
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: nanyu on November 17, 2009, 03:12:58 am
Hi, all, from the MinGW mail list, the new updated GDB.exe 7.02 is released, and the "setting bp issue on dll" is gone.


The GDB 7.02 can not work well with my project (a exe with named Demo2 and a dll named Tutorial04):

Code
> set prompt >>>>>>cb_gdb:
Reading symbols from F:\TC_Project\presearch\Demo2/bin/Debug/Demo2.exe...
done.
(gdb)
>>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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 disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source E:\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> handle SIGTRAP noprint
>>>>>>cb_gdb:
> directory F:/TC_Project/presearch/Tutorial04/
>>>>>>cb_gdb:
> directory F:/TC_Project/presearch/Demo2/
>>>>>>cb_gdb:
> break "F:/TC_Project/presearch/Demo2/Demo2Main.cpp:541"
Breakpoint 2 at 0x4082dc: file F:\TC_Project\presearch\Demo2\Demo2Main.cpp, line 541.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 920.0x404]
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

sometime ,I got :
Code
/*same as about*/
> run
gdb: windows_init_thread_list
[New Thread 4364.0x17b4]
WINDOWS\system32\winmm.dll" at 0x76b10000.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

--------
I have test It work well if use gdb-6.8 .

--------
code::blocks 5911 + mingw32 gcc 4.4.0 /windows xp / gdb 7.02
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: ollydbg on November 17, 2009, 03:20:43 am
Hi, all, from the MinGW mail list, the new updated GDB.exe 7.02 is released, and the "setting bp issue on dll" is gone.


The GDB 7.02 can not work well with my project (a exe with named Demo2 and a dll named Tutorial04):

Code
> set prompt >>>>>>cb_gdb:
Reading symbols from F:\TC_Project\presearch\Demo2/bin/Debug/Demo2.exe...
done.
(gdb)
>>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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 disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source E:\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> handle SIGTRAP noprint
>>>>>>cb_gdb:
> directory F:/TC_Project/presearch/Tutorial04/
>>>>>>cb_gdb:
> directory F:/TC_Project/presearch/Demo2/
>>>>>>cb_gdb:
> break "F:/TC_Project/presearch/Demo2/Demo2Main.cpp:541"
Breakpoint 2 at 0x4082dc: file F:\TC_Project\presearch\Demo2\Demo2Main.cpp, line 541.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 920.0x404]
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

--------
I have test It work well if use gdb-6.8 .

--------
code::blocks 5911 + mingw32 gcc 4.4.0 /windows xp / gdb 7.02


So, what's the problem? From the debugger log, it seems the GDB exit abnormally? Could you supply a test case?
At least it works on my test case of EXE and DLL project.
Title: Re: [OT] MinGW GDB 7.0 is released
Post by: nanyu on November 17, 2009, 04:12:13 am
...
So, what's the problem? From the debugger log, it seems the GDB exit abnormally? Could you supply a test case?
At least it works on my test case of EXE and DLL project.

1, New a  "SDL project" (by c::b's project template), named the project "SDL_WinMM_GDBTest" .

2, Add a new target named "DLL_Debug", and add the complie option -D_BUILD_DLL_.

3, modify the main.cpp, and build the "DLL_Debug" target.
Code
#if defined(_BUILD_DLL_)
int dll_main( int argc, char** argv )
#else
int main ( int argc, char** argv )
#endif
{
   ...
}

4, Create a C++ Console Project (by c::b's project template) , named "CallSDL_WinMM_GDBTest".

5, Add  a new  "Virtual target" to "CallSDL_WinMM_GDBTest" which alials is "DLL_Debug" and "Build targets contained": Debug.

6, the main.cpp for "CallSDL_WinMM..."
Quote
#include <iostream>
using namespace std;

int dll_main( int argc, char** argv );
int main(int argc, char** argv )
{
    dll_main(argc, argv);
   
    return 0;
}

7, Add two lib to CallDLL_WinMM_GDBTest's "Link libraries "
   SDL_WinMM_GDBTest.dll
   SDL

8, then add the linke search path...

9, build CallDLL_Win_GDBTest.exe , run it. It looks everythink OK, now.

10, Prerss F8, then the error message occurrences in Debugger(debug) log panel :
   
Code
Command-line: E:\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/CallSDL_WinMM_GDBTest.exe
Working dir : C:\Documents and Settings\ZhuangYanDell\My Documents\CodeBlocks Projects\CallSDL_WinMM_GDBTest\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\Documents and Settings\ZhuangYanDell\My Documents\CodeBlocks Projects\CallSDL_WinMM_GDBTest/bin/Debug/CallSDL_WinMM_GDBTest.exe...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source E:\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> handle SIGTRAP noprint
>>>>>>cb_gdb:
> directory C:/DOCUME~1/ZHUANG~1/MYDOCU~1/CODEBL~1/SDL_WI~1/
>>>>>>cb_gdb:
> directory C:/DOCUME~1/ZHUANG~1/MYDOCU~1/CODEBL~1/CALLSD~1/
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 5708.0x114c]
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

EDIT : I guess:  CallSDL_WinMM_GDBTest---call-->SDL_WinMM_GDBTest---call-->SDL.dll---call--->WinMM.dll. then the error occurrence.
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ollydbg on November 17, 2009, 04:22:23 am
Ok, too many steps. :? In fact, I have no experience of "SDL"...

I will test it.

By the way:would you mind to upload your project?

You can also try the project I uploaded in this message:
http://forums.codeblocks.org/index.php/topic,11301.msg77123.html#msg77123

Edit: Oh, my God, I need to setup a SDL build environment(headers, libraries...), tough for me...
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: nanyu on November 17, 2009, 05:58:20 am
Ok, too many steps. :? In fact, I have no experience of "SDL"...

I will test it.

By the way:would you mind to upload your project?

You can also try the project I uploaded in this message:
http://forums.codeblocks.org/index.php/topic,11301.msg77123.html#msg77123

Edit: Oh, my God, I need to setup a SDL build environment(headers, libraries...), tough for me...

1. download the sdl source here (http://www.libsdl.org/download-1.2.php) and unzip it.
2. starut msys , cd the sdl source dir
3. ./configure  -> make -> make install
4. in c::b, add a new global var : sdl
   copy include to $sdl.include
   copy /local/bin and local/lib  to $sdl.lib   

EDIT here is the test project package : sdl_gdb_dll_test (http://www.d2school.com/temp/sdl_dll_test.7z)

thanks you!
Title: Re: [OT] MinGW GDB 7.0.2 is released updated[2009-10-14]
Post by: ollydbg on January 13, 2010, 06:32:01 am
Just a reminder:
In the MinGW mail list:

Quote
From: 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 (http://forums.codeblocks.org/index.php/topic,11301.msg77274.html#msg77274)
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on January 13, 2010, 06:59:14 am
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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: 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
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Biplab on February 07, 2010, 05:16:06 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. :)
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: 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?
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ironhead on February 08, 2010, 02:10:33 am
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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 08, 2010, 07:58:55 am
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

Title: Debug Error Message
Post by: JZ on February 09, 2010, 06:02:45 am
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?

Title: Re: Debug Error Message
Post by: Jenna on February 09, 2010, 10:12:59 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" .

Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: 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.
Code
> 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.

Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Jenna on February 11, 2010, 07:55:55 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.
Code
> 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 ?
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Jenna on February 11, 2010, 08:29:35 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).
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Jenna on February 11, 2010, 08:32:56 pm
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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 12, 2010, 12:37:54 am
@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 (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 )



Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: 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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Jenna on February 12, 2010, 12:55:55 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.

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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 12, 2010, 01:06:57 am
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 (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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ironhead on February 13, 2010, 03:23:49 pm
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. ;)
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 23, 2010, 04:42:00 am
I just download the gdb snapshot from:

ftp://sourceware.org/pub/gdb/snapshots/branch/ (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... :(
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 23, 2010, 07:27:59 am
@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

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?
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ironhead on February 25, 2010, 06:41:30 pm
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/ (http://www.gnu.org/software/gdb/mailing-lists/)

The gdb devs are normally pretty quick to respond.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 26, 2010, 03:41:57 am
@ironhead:
Thanks, I posted a message in gdb maillist, also a bug report in the GDB Bugzilla.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 26, 2010, 10:36:30 am
@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:

Quote
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 :(

Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 27, 2010, 04:27:26 am
@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!

Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ironhead on February 27, 2010, 05:40:25 am
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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 27, 2010, 05:51:06 am
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?
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ironhead on February 28, 2010, 05:27:02 am
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.

Quote
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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 28, 2010, 02:20:23 pm
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
./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
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.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 28, 2010, 03:21:25 pm
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
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
--with-libexpat
??
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on February 28, 2010, 04:45:26 pm
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
./configure --with-expat

in this folder... :D
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on March 01, 2010, 07:30:39 am
Finally, I have successfully build gdb.exe with expat-1.dll support. Here are the major steps, I hope it can help others to build gdb.exe himself.

You need MSYS and MinGW installed in your system.

First, you need to build expat library.
1, Download the expat source.
2, Suppose your expat2.0.1 source code was located in c:\expat2.0.1, and you would like the generated dll installed in c:\install_expat
In MSYS, under /c/expat2.0.1, entering these command:
Code
./configure -prefix=/c/install_expat --enable-shared
3, make[press enter]
4, make install[press enter]
Then, you will have all the files in c:\install_expat. also, don't forget to run the strip command to strip the debug information. for example:
strip expat-1.dll will remove the strip information in this dll, and reduce the dll file size.

Second, build gdb
You need to copy all the files under c:\install_expat to c:\mingw, I suppose you have install MinGW in "c:\mingw", so, now, the compiler can find both the headers and libraries.

1, download the gdb source file, and unzip them, eg, they are extract to c:\gdb2010XXX
2, Create two empty folders, one is c:\obj_gdb, and the other is c:\install_gdb
3, in MSYS command, go to /c/obj_gdb
4, run these command:
Code
../gdb2010XXX/configure --prefix=/c/install_gdb  --with-expat
5, make[press enter] , this will build the gdb.exe and gdbserver.exe, take about half an hour in my P43.0 CPU.
6, make install[press enter]

After this, all the files were in c:\install_gdb
Also, don't forget to run the strip command to reduce the file size in c:\install_gdb\bin
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on March 13, 2010, 01:08:48 am
I have upload the gdb7.0.1 version to gdb7.0.1_ollydbg.7z (http://qp-gcc.googlecode.com/files/gdb7.0.1_ollydbg.7z).

I  built it in TDM GCC 4.4.1dw2, also, I have comment the warning statement in symtab.c of the gdb source, so there is no such warning now. Since the new GDB 7.0.50 version and the GDB branch 7.0.90 is still experience the watch wxString lag problem I statement before.

Also, I build this gdb.exe statically link the expat library, so you don't need expat-1.dll.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on March 19, 2010, 04:01:03 am
Hi, all.
today, gdb 7.1 official released, see here: GDB: The GNU Project Debugger (http://www.gnu.org/software/gdb/)

I have build this version under Loaden's GCC 4.4.3. I can debug under Codeblocks, but I still have some problems. the major problem is that showing variables in the Watch window of C::B, and the command interpreter runs really slow when I debug the Codecompletion plugin DLL.

See a more details in Asm_gmail - Re: gdb-7.1 - last call before release (Wed, Mar 17th) (http://sourceware.org/ml/gdb/2010-03/msg00162.html).

Can some one help me? you can build a gdb yourself, or you can test the gdb I built from gdb7.1.7z (http://qp-gcc.googlecode.com/files/gdb7.1.7z)

Thanks.

Edit
You can compare these two version of gdb
gdb7.0.1_ollydbg.7z (http://qp-gcc.googlecode.com/files/gdb7.0.1_ollydbg.7z), I build from TDM gcc 4.4.1dw2,with static expat library, based on the official gdb 7.0.1 source code, and I only comment out the #psymbal warning message.
and
gdb7.1.7z (http://qp-gcc.googlecode.com/files/gdb7.1.7z), I built from Loaden gcc 4.4.3, with static expat library, based on the official gdb 7.1 source code.

You will notice that the first one gdb7.0.1_ollydbg.7z (http://qp-gcc.googlecode.com/files/gdb7.0.1_ollydbg.7z) runs really faster then the second one.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: oBFusCATed on March 19, 2010, 10:45:59 am
Ah, great... time to test gdb_mi with this :)
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Loaden on March 19, 2010, 11:30:04 am
I have build this version under Loaden's GCC 4.4.3. I can debug under Codeblocks, but I still have some problems. the major problem is that showing variables in the Watch window of C::B, and the command interpreter runs really slow when I debug the Codecompletion plugin DLL.
In here, there is no delay, very fast! :lol:
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on March 21, 2010, 06:28:25 am
Just a reminder:
Today, Chirs has announced an offcial mingw gdb 7.1 in the mingw maillist:

Quote
I've uploaded a new mingw gdb build created from the vanilla gdb 7.1 sources:

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

The sources can be found here:

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

Please report any issues to this mailing list.

Chris

I have tested it and found that this one can't debug into a dll source. The same as this bug report and discussion:
Re: [OT] MinGW GDB 7.0 is released (http://forums.codeblocks.org/index.php/topic,11301.msg77273.html#msg77273)

Thanks.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: Loaden on March 21, 2010, 08:00:46 am
I have build this version under Loaden's GCC 4.4.3. I can debug under Codeblocks, but I still have some problems. the major problem is that showing variables in the Watch window of C::B, and the command interpreter runs really slow when I debug the Codecompletion plugin DLL.
In here, there is no delay, very fast! :lol:
I'm sorry, that my original testing method was wrong, now, I have exprenced the debug lag problem too.( using gdb 7.1)

Here is the instrucntions to reproduce the problem:

1, start debugging
2, set a breakpoint in the parserthread.cpp, line 450
3, add a watch variable: token, which is a wxString
4, when the debugger reach the breakpoint, you will notice the debugger toolbar will disabled for several seconds.
5, then, you will see the token's value in "watch window".
6, you press "step" button in the debugger toolbar.
7, you will notice that the toolbar disabled agian for a few seconds, and the lag happens again.

I have trid the mingw gdb 7.0.1, these is no such time delay probelm.
Title: Re: [OT] MinGW GDB 7.0.1 is released in 2010 01 07
Post by: ollydbg on May 22, 2010, 07:53:58 am
Hi, all.

I have successfully built the mingw gdb 7.1.50 snapshot from the source gdb-7.1.50.20100521. tar.bz2 (http://ftp://sourceware.org/pub/gdb/snapshots/current/gdb-7.1.50.20100521.tar.bz2) link to expat static library (under Loaden's mingw 4.4.4 and Msys)

You can download it from gdb-7.1.50.20100521.7z (http://qp-gcc.googlecode.com/files/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!!

ollydbg
Title: Re: [OT] ollydbg's unoffcial MinGW GDB 7.1.50-20100521 released
Post by: ollydbg on June 14, 2010, 10:29:39 am
Updated 2010-06-15
I found that the gdb.exe build from tdm-gcc 4.5 lacks iconv library, this will cause the problem like: Bug 10908 - error reading variable for char variable (http://sourceware.org/bugzilla/show_bug.cgi?id=10908), So, I rebuild the gdb under Loaden's GCC 4.4.4, now, it works fine, so, I suggest you need to download the file gdb-7.1.50.20100613withpython-2.7z (http://qp-gcc.googlecode.com/files/gdb-7.1.50.20100613withpython-2.7z)

2010-06-14
Hi, all. Today, I have build the latest gdb CVS under TDM-MinGW 4.5 dw2 with python support.

Firstly, you need to install the python environment, I use header file and libs in this package python Python 2.6.5 Windows installer (http://www.python.org/ftp/python/2.6.5/python-2.6.5.msi)

the gdb package can be downloaded from Loaden's site: gdb-7.1.50.20100613withpython-2.7z (http://qp-gcc.googlecode.com/files/gdb-7.1.50.20100613withpython-2.7z)

Now, I have testing the pretty print function of python, it works fine!! :D

There are the brief steps to use the pretty print function. I mainly followed STLSupport - GDB Wiki (http://sourceware.org/gdb/wiki/STLSupport)

The only difference is that, you can create a single *.gdb file, then use this command  "source *.gdb"  instead of using a .gdbinit file.

Then you can add it here: in the debugger setting dialog, see attachment image

Also, I think many py pretty printers can be added, like the wxWidgets support.
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/misc/gdb/print.py



[attachment deleted by admin]
Title: Re: [OT] ollydbg's unoffcial MinGW GDB 7.1.50-20100521 released
Post by: ollydbg on June 14, 2010, 10:33:40 am
Here is the test code:
Code
#include <iostream>
#include <string>
#include <vector>

using namespace std;

typedef vector<string> vstr;

int main()
{
    vstr vvvv;
    vvvv.push_back("bla bla");
    vvvv.push_back("aaabbb");
    string v0 = vvvv[0];
    cout << "Hello world!" << endl;

    return 0;
}

Then ,you can enter "print vvvv" in the debugger edit control, and here is the log output:

Quote
> print vvvv
$2 = std::vector of length 2, capacity 2 = {"bla bla", "aaabbb"}
>>>>>>cb_gdb:
Title: Re: [OT] ollydbg's unoffcial MinGW GDB gdb-7.1.50.20100623 with python released
Post by: ollydbg on June 24, 2010, 08:10:24 am
Just a reminder, the new gdb version with wxWidgets and stl python script released. see the updated OP
[OT] ollydbg's unoffcial MinGW GDB gdb-7.1.50.20100623 with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
Title: Re: [OT] ollydbg's unoffcial MinGW GDB gdb-7.1.50.20100623 with python released
Post by: nenin on June 24, 2010, 06:37:38 pm
Lokks like it works. Thanks!
Where I can find instructions to prepare pretty printer for class? Actually I now need it just for std::vallaray.   
Title: Re: [OT] ollydbg's unoffcial MinGW GDB gdb-7.1.50.20100623 with python released
Post by: ollydbg on June 24, 2010, 06:44:00 pm
Lokks like it works. Thanks!
Where I can find instructions to prepare pretty printer for class? Actually I now need it just for std::vallaray.   

Nice.
You can see this wiki page:
STLSupport - GDB Wiki (http://sourceware.org/gdb/wiki/STLSupport)
So, I think you can see the python script in the GCC's trunk.
By the way, it seems the Latest svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python does not works correctly. I just use an old revision.

You can see the web page's of Tom( he is the main dev of GDB)
7. Pretty printing, part 1 « The Cliffs of Inanity (http://tromey.com/blog/?p=524)

Title: Re: [OT] ollydbg's unoffcial MinGW GDB gdb-7.2.50.20100708 with python released
Post by: ollydbg on July 09, 2010, 01:25:08 am
Just a reminder:
New gdb cvs version was released.See
[OT] ollydbg's unoffcial MinGW GDB gdb-7.2.50.20100708 with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
Title: Re: [OT] unoffcial MinGW GDB gdb-7.2 with python released
Post by: ollydbg on September 05, 2010, 02:55:36 pm
Hi, new gdb 7.2 for windows is released.

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 to 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 (http://qp-gcc.googlecode.com/files/gdb-7.2.7z)
Thanks loaden for the build.


Have a try!!!
Title: Re: [OT] unoffcial MinGW GDB gdb-7.2 with python released
Post by: ollydbg on September 08, 2010, 01:20:39 pm
The build steps( corss build windows gdb from linux) are list here in

http://code.google.com/p/qp-gcc/wiki/CrossbuildGDB


Title: Re: [OT] unoffcial MinGW GDB gdb-7.2 with python released
Post by: ollydbg on December 13, 2010, 03:35:28 pm
reminder:

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 (http://qp-gcc.googlecode.com/files/gdb-7.2.50.20101213.7z)
You need to have python 2.7.1 installed on your system.

I'm really appreciate to xunxun1982 (http://forums.codeblocks.org/index.php?action=profile;u=12871)'s help!!!
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on December 14, 2010, 01:38:47 am
strange, my last post
Quote
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 (http://qp-gcc.googlecode.com/files/gdb-7.2.50.20101213.7z)
You need to have python 2.7.1 installed on your system.

I'm really appreciate to xunxun1982 (http://forums.codeblocks.org/index.php?action=profile;u=12871)'s help!!!

was list in the Recent Posts (http://forums.codeblocks.org/index.php?action=recent;start=10)

but when I click the link :
http://forums.codeblocks.org/index.php/topic,11301.msg93230.html#msg93230

I still can't see that post  :(

Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on December 17, 2010, 03:56:55 am
guys, I just update this wiki page GDB (http://code.google.com/p/qp-gcc/wiki/GDB) to introduce how to upgrade to the latest gdb.

See the last section of GDB (http://code.google.com/p/qp-gcc/wiki/GDB).
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on January 10, 2011, 04:09:33 am
I just update the original page:

1, a new cvs version is released for download.
2, a full steps description to build gdb on MinGW+MSYS is added.

see:
[OT] unoffcial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)

thanks.

ollydbg
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: Borr on March 10, 2011, 08:42:11 am
I have a Unicode build wxWidgets 2.8.10, gdb-7.2.50.20101213 with python, MinGW 4.4.1, OS: WinXP SP3, C::B 10.05.
Quote
(gdb) show charset
The host character set is "auto; currently CP1251".
The target character set is "auto; currently CP1251".
The target wide character set is "auto; currently UTF-16".

My problem is that I can debug wxString (not English). In the debug window I can see is not readable symbols(Is Like "\320\363\367\355\356\351 \357\360\350\365\356\344" instead of "Проба"). Has anyone solved this problem?
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: oBFusCATed on March 10, 2011, 10:14:30 am
What is the charset of your string?
Have you tried the python pretty printers for wxWidgets?
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: Borr on March 10, 2011, 10:22:32 am
I updated C::B to rev 7017 and it will work.

Quote
What is the charset of your string?

system cp1251; C::B UTF-8; console cp866.

Quote
Have you tried the python pretty printers for wxWidgets?

Yes
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on March 29, 2011, 03:10:17 pm
FYI:
xunxun1982 (http://forums.codeblocks.org/index.php?action=profile;u=12871) has release a gcc mingw 32 package
MinGW_gcc4.5.3.20110324_static_win32.7z (http://pcxprj.googlecode.com/files/MinGW_gcc4.5.3.20110324_static_win32.7z)
which include a new gdb 7.2.50 20110319 with python support.


I just found that there was a crash using gdb 7.2.50 20110319 when debugging c::b under c::b, and I build a new one
gdb-7.2.50.20110401.7z (http://qp-gcc.googlecode.com/files/gdb-7.2.50.20110401.7z)

welcome to test it. :D
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on May 09, 2011, 09:36:12 am
FYI:
xunxun1982 (http://forums.codeblocks.org/index.php?action=profile;u=12871) has release a gcc mingw 32 package

MinGW_gcc4.5.4.20110428_static_win32.7z (http://pcxprj.googlecode.com/files/MinGW_gcc4.5.4.20110428_static_win32.7z)
which include a new gdb 7.3.50 20110430 with python support.

also a portable c::b Portable_CodeBlocks_svn7128.7z (http://code.google.com/p/pcxprj/downloads/detail?name=Portable_CodeBlocks_svn7128.7z&can=2&q=)

More information can be found on his site:pcxprj (http://code.google.com/p/pcxprj/)
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on May 12, 2011, 01:31:56 pm
FYI:
I create a wiki page on how to build gdb under msys+mingw.
see:
http://code.google.com/p/qp-gcc/wiki/build_gdb_msys_en
Title: Re: [OT] unoffcial MinGW GDB gdb with python released
Post by: ollydbg on June 06, 2011, 07:50:04 am
updated the gdb cvs mingw build on 2011-06-04
see [OT] unoffcial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)  for more details.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 03, 2011, 05:20:31 am
update the GDB binary to 20110802 with some Windows Patches.
See [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 04, 2011, 05:12:25 am
Sorry, the 20110802 has some problems, and I fixed it by updating to a new 20110804 build. see [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for some details.
Sorry for the inconvenience.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: codeur on August 05, 2011, 06:27:42 am
Thanks ollydbg for maintaining the unofficial MinGW gdb with python, and also for the translation to English of the "wiki page on how to build gdb". Both are very useful!

Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 05, 2011, 08:58:24 am
Thanks ollydbg for maintaining the unofficial MinGW gdb with python, and also for the translation to English of the "wiki page on how to build gdb". Both are very useful!
You are welcome. Happy sharing!!!
Today, I have also updated the wiki (English version) to the latest build steps, see the first post of this thread.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MindVortex on August 09, 2011, 09:16:26 pm
Hi ollydbg! I specifically registered on this forum to ask you this question :-) Is it possible for you to post a 64-bit version of your python-enabled gdb?..
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: xunxun on August 09, 2011, 09:35:22 pm
Hi ollydbg! I specifically registered on this forum to ask you this question :-) Is it possible for you to post a 64-bit version of your python-enabled gdb?..
Ollydbg doesn't have 64bit OS...
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 10, 2011, 03:26:41 am
Hi ollydbg! I specifically registered on this forum to ask you this question :-) Is it possible for you to post a 64-bit version of your python-enabled gdb?..
As xunxun said, I do not have a 64bit windows system. so I can't build a native 64bit windows gdb. I guess that you can follow my instructions in the first post and build it yourself. Or I have searched on Google for you and found that you can download on from:
1, read the following posts here: http://lists.qt.nokia.com/pipermail/qt-creator/2011-March/008626.html
2, go to ftp here: ftp://ftp.qt.nokia.com/misc/gdb/7.2/
That's all I can help you.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 10, 2011, 04:19:45 am
BUMP:
the 2011-08-10 version just has auto-loaded gdb's own python script support for pretty-printer. see
[OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.  :D
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MindVortex on August 10, 2011, 10:43:48 am
Thank you anyhow! I'll see what I can do.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on August 17, 2011, 05:34:52 pm
BUMP:
the 2011-08-10 version just has auto-loaded gdb's own python script support for pretty-printer. see
[OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.  :D

It works ... but I found odd thing: sometimes gdb crashed on start. Looks like it try to prepare non-initialized local variables in main for pretty-printing. At least switch off corresponding option in Setting results in stable (and really fast) further operation.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 18, 2011, 03:16:55 am
It works ... but I found odd thing: sometimes gdb crashed on start. Looks like it try to prepare non-initialized local variables in main for pretty-printing. At least switch off corresponding option in Setting results in stable (and really fast) further operation.
Did you mean like below:
Code
int main()
{
int a;// set breakpoint here

vector<string> b;

}
Then, you try to use pretty printer to show the variable b?
surely, b is non-initialized local variable, and this will let gdb/python script go to some un-expected behavior, like go infinite loop to show its member.

This is a known bug, I have discussed this bug in this forum before. I also have a workaround patch on GDB to compare the line number between the current PC address and the variable line, then try to filter out the non-initialized local variable. But I do not think this patch will be much reliable.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on August 18, 2011, 12:37:31 pm
Did you mean like below:
Code
int main()
{
int a;// set breakpoint here

vector<string> b;

}
Then, you try to use pretty printer to show the variable b?
surely, b is non-initialized local variable, and this will let gdb/python script go to some un-expected behavior, like go infinite loop to show its member.
I did not. But C::B did it by default, in "Local variables" section of watch.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 18, 2011, 02:57:03 pm
I did not. But C::B did it by default, in "Local variables" section of watch.
En, that's the same thing I said in my previous post.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on August 18, 2011, 05:04:59 pm
I did not. But C::B did it by default, in "Local variables" section of watch.
En, that's the same thing I said in my previous post.
I suggest to highlight this problem, in header. 
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on August 27, 2011, 05:29:02 pm
I found other issue. This declaration:
Code
const static std::string apms[5]={"&amp;","&lt;","&gt;","&quot;","&apos;"};
kills GDB.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 28, 2011, 03:07:12 am
I found other issue. This declaration:
Code
const static std::string apms[5]={"&amp;","&lt;","&gt;","&quot;","&apos;"};
kills GDB.
I just test it and works here.(WinXP, MinGW GCC 4.6.1)

see the debug log:
Quote
> p apms
$1 = {"&amp;", "&lt;", "&gt;", "&quot;", "&apos;"}
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on August 31, 2011, 06:56:18 pm

see the debug log:
Quote
> p apms
$1 = {"&amp;", "&lt;", "&gt;", "&quot;", "&apos;"}
It works in gdb console. But in C::B watch  dgb fell. I use last TDM - dwarf, 7.3.50.20110810-cvs and CB::B 10.05
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on September 01, 2011, 04:58:48 am

see the debug log:
Quote
> p apms
$1 = {"&amp;", "&lt;", "&gt;", "&quot;", "&apos;"}
It works in gdb console. But in C::B watch  dgb fell. I use last TDM - dwarf, 7.3.50.20110810-cvs and CB::B 10.05

It works here.

1. c::b 10.05 is too old, I suggest you should use the latest nightly build debugger branch version.
2. you need to open the "Debugger settings" dialog, then uncheck the "enable watch script" option, if you use python based gdb. (I noticed that if you check this option when using python pretty printer, there will be a crash on gdb).


Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on September 01, 2011, 04:02:01 pm
1. c::b 10.05 is too old, I suggest you should use the latest nightly build debugger branch version.
1. Tank you for operative response.
2. How stable nightly build version is?
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: oBFusCATed on September 01, 2011, 04:07:42 pm
If you turn off CC it is very stable :)
If you use CC there are some crashes...
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on September 02, 2011, 01:59:36 pm
If you turn of CC it is very stable :)
If you use CC there are some crashes...
What is "CC"?  :?
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: oBFusCATed on September 02, 2011, 02:04:20 pm
Code completion.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on September 02, 2011, 02:09:10 pm
Code completion.
I forgot about it since return from Delphi to C++.   :D
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: nenin on September 02, 2011, 02:57:43 pm
1. c::b 10.05 is too old, I suggest you should use the latest nightly build debugger branch version.
2. you need to open the "Debugger settings" dialog, then uncheck the "enable watch script" option, if you use python based gdb. (I noticed that if you check this option when using python pretty printer, there will be a crash on gdb).
Confirmed. Works with  svn7387.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on November 08, 2011, 02:08:07 pm
2011-11-08 release
Pre-build binary can be found in gdb2011-11-08cvs.7z (http://qp-gcc.googlecode.com/files/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 (http://sourceware.org/ml/gdb-patches/2011-11/msg00141.html) and Re: configure file to debug codecompletion plugin (http://forums.codeblocks.org/index.php/topic,12951.msg104087.html#msg104087)

Watchpoint can be used in both gdb.exe and gdbserver.exe, see: brobecke - src/gdb/gdbserver ChangeLog win32-i386-low.c (http://sourceware.org/ml/gdb-cvs/2011-11/msg00039.html)

The total diff file to the gdb cvs head source can be found in: gdb2011-11-08cvs.diff (http://qp-gcc.googlecode.com/files/gdb2011-11-08cvs.diff)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on January 19, 2012, 02:57:54 pm
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 (http://qp-gcc.googlecode.com/files/gdb2012-01-19.7z), it is gdb's latest cvs version with my patch (http://qp-gcc.googlecode.com/files/gdb2012-01-19.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 (http://sourceware.org/ml/gdb-patches/2012-01/msg00676.html) 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.

EDIT 2012-02-16
Update to new release, and fix a tiny regression since 2011-12-12.
See more details in the first post in this thread.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on May 22, 2012, 10:10:27 am
Bump to GDB cvs 2012-05-22, see the first post for download link and more information.  :)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on August 19, 2012, 03:13:24 pm
Bump to gdb cvs 2012-08-17, see the download links in the first post. (gdb 7.5 is already released, but I still prefer using the cvs head :))
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on December 16, 2012, 04:04:30 pm
Bump to gdb cvs 2012-12-15, see the first post: [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 04, 2013, 03:37:23 pm
Bump to 2013-02-04 release, the "filename display format" patch was now already in gdb cvs, see the first post for more information.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on June 08, 2013, 02:46:44 am
Updated to GDB cvs 2013-06-08, see the [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: golgepapaz on July 06, 2013, 12:08:21 am
Since I am one of those unlucky souls suffering from the dreaded message
'Cannot evaluate function -- may be inlined' while trying to see a string
at the watch window, I'd  thought to give it another try with a recent
version of gdb with python support which I've built with the help of instructions
from the http://code.google.com/p/qp-gcc/wiki/build_gdb_msys_en

Code
Starting debugger: C:\MinGW\bin\gdb.exe -nx -fullname  -quiet  -args E:/codeblocks_svn/src/devel/codeblocks.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from E:\codeblocks_svn\src\devel\codeblocks.exe...(no debugging symbols found)...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version

Reading symbols from E:\codeblocks_svn\src\devel\codeblocks.exe...(no debugging symbols found)...done.

[debug]GNU gdb (GDB) 7.6.50.20130705-cvs
[debug]Copyright (C) 2013 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.6.50.20130705-cvs
Yup, right off the head. Although I've failed to build it at first
because of the reading fail of the warning about the line endings.

Anyway, with still no joy and seeing the same dreaded message
about strings.I've turned on the full debug log and hovering over
a string variable I noticed this.

Code
[debug]> whatis fileToParse
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output &fileToParse
[debug](std::string *) 0x3f0fd14>>>>>>cb_gdb:
[debug]> output fileToParse.c_str()[0]@fileToParse.size()
[debug]Cannot evaluate function -- may be inlined
[debug]>>>>>>cb_gdb:

Cannot evaluate function -- may be inlined

whereas using the commands <print> or <output> from the debugger
log window prints the string nicely.
Code
> p fileToParse

[debug]> p fileToParse
[debug]$5337 = "E:\\c++11.denemeler\\clang_cc\\TestFiles\\classtest.cpp"
[debug]>>>>>>cb_gdb:

$5337 = "E:\\c++11.denemeler\\clang_cc\\TestFiles\\classtest.cpp"
> output fileToParse

[debug]> output fileToParse
[debug]"E:\\c++11.denemeler\\clang_cc\\TestFiles\\classtest.cpp">>>>>>cb_gdb:

"E:\\c++11.denemeler\\clang_cc\\TestFiles\\classtest.cpp"

So I am guessing that debugger plugin is sending the wrong commands to the debugger
Is there a way to fix this?

Edit: Oh darn it.I've just noticed there is a option for disabling watch scrips if you are using python
enabled gdb in debugger configuration window.All is well I can see my strings now.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on July 06, 2013, 05:43:32 pm
...
Edit: Oh darn it.I've just noticed there is a option for disabling watch scrips if you are using python
enabled gdb in debugger configuration window.All is well I can see my strings now.
Good to hear this. In fact, your problem was discussed in our forum before, see: Re: The 25 August 2012 build (8248) is out. (http://forums.codeblocks.org/index.php/topic,16772.msg114299.html#msg114299)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on October 09, 2013, 03:12:17 am
Bump: a new release is here, it fix a bug in FYI: GDB has a big bug to support MinGW GCC (4.7.x and later) (http://forums.codeblocks.org/index.php/topic,18403.0.html), please see the first page [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details. Thanks.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on January 14, 2014, 01:29:35 am
Bump: a new release 2014-01-14 is here. Updated page [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.0.html) gives you more details. Thanks.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on May 23, 2014, 03:07:14 am
Updated.
2014-05-23
gdb2014-05-23.zip (http://sourceforge.net/projects/gdbmingw/files/gdb2014-05-23.zip/download) with patches against GDB GIT HEAD (http://sourceforge.net/projects/gdbmingw/files/gdb2014-05-23patches.zip/download) 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 (https://sourceware.org/bugzilla/show_bug.cgi?id=15806).
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on January 28, 2016, 08:50:49 pm
...long time no update...

As the debugger in TDM 5.1.0 still crashes for wx projects in general and TDM does not seem to fix it shortly, I'd like to see an update of this one, if possible.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on January 29, 2016, 01:32:45 pm
...long time no update...

As the debugger in TDM 5.1.0 still crashes for wx projects in general and TDM does not seem to fix it shortly, I'd like to see an update of this one, if possible.
I personally build GDB months ago(I have not uploaded yet), I will build and upload the GDB git head this weekend
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on January 30, 2016, 08:32:37 am
FYI: Hi all, I have release a new build, which is GDB 2016-01-30, see the updated first post  [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.0.html) for details.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on January 30, 2016, 10:37:10 am
FYI: Hi all, I have release a new build, which is GDB 2016-01-30, see the updated first post  [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.0.html) for details.
Great, thanks! I'll definitely give it a shot. (I have no other choice anyways... LOL.)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on January 31, 2016, 05:52:32 pm
FYI: Hi all, I have release a new build, which is GDB 2016-01-30, see the updated first post  [OT] unofficial MinGW GDB gdb with python released (http://forums.codeblocks.org/index.php/topic,11301.0.html) for details.
Well too bad. Now this debugger also fails to debug wxWidgets applications on Windows. The error is:

Quote
[debug]Error while reading shared library symbols for D:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll:
[debug]D:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll: error reading symbols
[debug]C:/crossdev/src/gdb-7.9.1/gdb/buildsym.c:1023: internal-error: prepare_for_building: Assertion `current_subfile == NULL' failed.
[debug]A problem internal to GDB has been detected,
[debug]further debugging may prove unreliable.
[debug]This is a bug, please report it.  For instructions, see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]This application has requested the Runtime to terminate it in an unusual way.
[debug]Please contact the application's support team for more information.

Does it work for you?
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on January 31, 2016, 06:13:09 pm
Well too bad. Now this debugger also fails to debug wxWidgets applications on Windows. The error is:
Aaaarg! nevermind - I picked the wrong debugger.
@Teodor: Is it possible the clearly show the name of the debugger chosen before a debug session starts? This happens rather often to me... as I switch often...

However - I see another issue: "Import error: site" and that's it. :-/ Looks like the python stuff is broken for me...
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: oBFusCATed on January 31, 2016, 06:25:05 pm
You want to see the name of the selected debugger configuration, right?
I think we print the path to the debugger already.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on January 31, 2016, 07:39:37 pm
I think we print the path to the debugger already.
Yes, we do. And on the very top the debugger configuration is shown as well. This can be well overseen. Any change to at least colour the debugger config in blue, bold or alike?

And no fun: This debugger CRASHES with wx, too. I thought it would not, but after adding Python (32 bit) DLL and PATH I see this crash:

[debug]Error while reading shared library symbols for D:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll:
[debug]D:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll: error reading symbols
[debug]../../binutils-gdb/gdb/buildsym.c:1036: internal-error: void prepare_for_building(const char*, CORE_ADDR): Assertion `current_subfile == NULL' failed.
[debug]A problem internal to GDB has been detected,
[debug]further debugging may prove unreliable.
[debug]This is a bug, please report it.  For instructions, see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]This application has requested the Runtime to terminate it in an unusual way.
[debug]Please contact the application's support team for more information.


Anybody that can confirm the issue? It also happens on the command line, btw. I am trying to debug the debug version of Code::Blocks as you see. standard "Hello World" works.


Edit: Its the same error as with TDM now, btw.. Not the very same, as the path differs. So its really the new ollydbg debugger. I need to switch back to the old one. :-(
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: oBFusCATed on January 31, 2016, 08:01:47 pm
Any change to at least colour the debugger config in blue, bold or alike?
It should be possible. Probably it will be easiest to tweak it to the way you like it.:)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 01, 2016, 06:09:24 am
I think we print the path to the debugger already.
Yes, we do. And on the very top the debugger configuration is shown as well. This can be well overseen. Any change to at least colour the debugger config in blue, bold or alike?

And no fun: This debugger CRASHES with wx, too. I thought it would not, but after adding Python (32 bit) DLL and PATH I see this crash:

[debug]Error while reading shared library symbols for D:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll:
[debug]D:\Devel\CodeBlocks\src\devel\wxmsw28u_gcc_custom.dll: error reading symbols
[debug]../../binutils-gdb/gdb/buildsym.c:1036: internal-error: void prepare_for_building(const char*, CORE_ADDR): Assertion `current_subfile == NULL' failed.
[debug]A problem internal to GDB has been detected,
[debug]further debugging may prove unreliable.
[debug]This is a bug, please report it.  For instructions, see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]This application has requested the Runtime to terminate it in an unusual way.
[debug]Please contact the application's support team for more information.


Anybody that can confirm the issue? It also happens on the command line, btw. I am trying to debug the debug version of Code::Blocks as you see. standard "Hello World" works.


Edit: Its the same error as with TDM now, btw.. Not the very same, as the path differs. So its really the new ollydbg debugger. I need to switch back to the old one. :-(
I don't have this kind of issue in my system, as I'm using debug version of wx2.8 and debug version of wx 3.0.2 and git header. This is what I am going to do:
1, use some release version of wx 2.8
2, I will try to use GDB from TDM and see whether it has such error.

Will report back soon.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 01, 2016, 07:13:57 am
Hi, Morten, I guess this is an GCC issue comes from TDM's GCC. I just have those test environment:
1, I have a wx 2.8 release which is built by "MinGW-Build 4.8.1 dw2" (Note MinGW-Build 4.8.1 comes from MinGW-W64 project)
2, I build C::B against this wx 2.8, but I build it with "MinGW-Build 4.9. dw2".
3, I can debug C::B under my build GDB(2016-01-30) without any issue.

Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 01, 2016, 07:43:36 am
Morten, I did another dummy test.

I just download the binary files from our 16.01 release, and unzip it.
I then create a very dummy project, and I set the output file to the codeblocks.exe and add all the necessary args like below:
Code
--debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose -p debug
Then I can debug this dummy project.
Then I see I can correctly debug the codeblocks.exe(also no debug information inside the exe and dlls), and I see all dlls are loaded correctly, and no error reported. This means my GDB dose not report the error when loading the wx dll build from TDM gcc(I think our 16.01 release binary was build from TDM GCC, right?)

Here is the full log, you can have a look, I can pause the debugee, and print all the shared libraries:
Code
[debug]Command-line: E:\code\gdb\mybuild\bin\gdb.exe -nx -fullname -quiet  -args E:/code/cb/16.01/codeblocks-16.01-nosetup/codeblocks.exe
[debug]Working dir : D:\temp\hihihi

Starting debugger: E:\code\gdb\mybuild\bin\gdb.exe -nx -fullname -quiet  -args E:/code/cb/16.01/codeblocks-16.01-nosetup/codeblocks.exe
done

[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!

Setting breakpoints

[debug]Reading symbols from E:/code/cb/16.01/codeblocks-16.01-nosetup/codeblocks.exe...(no debugging symbols found)...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version

Reading symbols from E:/code/cb/16.01/codeblocks-16.01-nosetup/codeblocks.exe...(no debugging symbols found)...done.

[debug]GNU gdb (GDB) 7.10.50.20160130-git
[debug]Copyright (C) 2016 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.10.50.20160130-git

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source E:\code\gdb\mybuild\bin\my.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory D:/temp/hihihi/
[debug]Source directories searched: D:/temp/hihihi;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> set args --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose -p debug
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: E:\code\cb\16.01\codeblocks-16.01-nosetup\codeblocks.exe --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose -p debug

Child process PID: 2948

[debug][New Thread 2948.0xe64]
[debug][New Thread 2948.0xf4c]
[debug][New Thread 2948.0x4b4]
[debug][New Thread 2948.0xcf8]
[debug][New Thread 2948.0x9e8]
[debug][New Thread 2948.0x758]
[debug][New Thread 2948.0x2e4]
[debug][New Thread 2948.0x5d4]
[debug][New Thread 2948.0xb8c]
[debug][New Thread 2948.0xe74]

Trying to interrupt process with pid: 2948; child pid: 2948 gdb pid: 2524

[debug][Thread 2948.0xe74 exited with code 0]
[debug][New Thread 2948.0xea4]
[debug]Thread 11 received signal SIGTRAP, Trace/breakpoint trap.
[debug][Switching to Thread 2948.0xea4]
[debug]0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
[debug]>>>>>>cb_gdb:

In ntdll!DbgBreakPoint () (C:\WINDOWS\system32\ntdll.dll)

[debug]> bt 30
[debug]#0  0x7c90120f in ntdll!DbgBreakPoint () from C:\WINDOWS\system32\ntdll.dll
[debug]#1  0x7c952119 in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\system32\ntdll.dll
[debug]#2  0x00000005 in ?? ()
[debug]#3  0x00000004 in ?? ()
[debug]#4  0x00000001 in ?? ()
[debug]#5  0x06feffd0 in ?? ()
[debug]#6  0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:

> info shared

[debug]> info shared
[debug]From        To          Syms Read   Shared Object Library
[debug]0x7c901000  0x7c9b1ee0  Yes (*)     C:\WINDOWS\system32\ntdll.dll
[debug]0x7c801000  0x7c8f5cd8  Yes (*)     C:\WINDOWS\system32\kernel32.dll
[debug]0x5d091000  0x5d12907c  Yes (*)     C:\WINDOWS\system32\comctl32.dll
[debug]0x77dd1000  0x77e6aaf8  Yes (*)     C:\WINDOWS\system32\advapi32.dll
[debug]0x77e71000  0x77f02554  Yes (*)     C:\WINDOWS\system32\rpcrt4.dll
[debug]0x77fe1000  0x77ff0888  Yes (*)     C:\WINDOWS\system32\secur32.dll
[debug]0x77f11000  0x77f58878  Yes (*)     C:\WINDOWS\system32\gdi32.dll
[debug]0x7e411000  0x7e4a0de4  Yes (*)     C:\WINDOWS\system32\user32.dll
[debug]0x77c11000  0x77c67d74  Yes (*)     C:\WINDOWS\system32\msvcrt.dll
[debug]0x7c9c1000  0x7d1d6510  Yes (*)     C:\WINDOWS\system32\shell32.dll
[debug]0x77f61000  0x77fd59d4  Yes (*)     C:\WINDOWS\system32\shlwapi.dll
[debug]0x76781000  0x767881cc  Yes (*)     C:\WINDOWS\system32\shfolder.dll
[debug]0x6cc41000  0x6d3dcdc8  Yes         E:\code\cb\16.01\codeblocks-16.01-nosetup\wxmsw28u_gcc_cb.dll
[debug]0x763b1000  0x763f84dc  Yes (*)     C:\WINDOWS\system32\comdlg32.dll
[debug]0x774e1000  0x7761d110  Yes (*)     C:\WINDOWS\system32\ole32.dll
[debug]0x77121000  0x771aa42c  Yes (*)     C:\WINDOWS\system32\oleaut32.dll
[debug]0x76b41000  0x76b6c8b4  Yes (*)     C:\WINDOWS\system32\winmm.dll
[debug]0x73001000  0x7302551c  Yes (*)     C:\WINDOWS\system32\winspool.drv
[debug]0x71ad1000  0x71ad804c  Yes (*)     C:\WINDOWS\system32\wsock32.dll
[debug]0x71ab1000  0x71ac6dc8  Yes (*)     C:\WINDOWS\system32\ws2_32.dll
[debug]0x71aa1000  0x71aa7320  Yes (*)     C:\WINDOWS\system32\ws2help.dll
[debug]0x617c1000  0x61dfe600  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\codeblocks.dll
[debug]0x6e441000  0x6e50a86c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxpropgrid.dll
[debug]0x66e41000  0x66e4c3d0  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\exchndl.dll
[debug]0x61541000  0x6157b2fc  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\mgwhelp.dll
[debug]0x03001000  0x03148ce4  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\dbghelp.dll
[debug]0x76bf1000  0x76bfa3c4  Yes (*)     C:\WINDOWS\system32\psapi.dll
[debug]0x77c01000  0x77c07300  Yes (*)     C:\WINDOWS\system32\version.dll
[debug]0x76391000  0x763acc6c  Yes (*)     C:\WINDOWS\system32\imm32.dll
[debug]0x629c1000  0x629c828e  Yes (*)     C:\WINDOWS\system32\lpk.dll
[debug]0x74d91000  0x74dfa696  Yes (*)     C:\WINDOWS\system32\usp10.dll
[debug]0x773d1000  0x774d2e2c  Yes (*)     C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll
[debug]0x74721000  0x7476bc4c  Yes (*)     C:\WINDOWS\system32\MSCTF.dll
[debug]0x755c1000  0x755edba0  Yes (*)     C:\WINDOWS\system32\MSCTFIME.IME
[debug]0x01511000  0x017d4448  Yes (*)     C:\WINDOWS\system32\xpsp2res.dll
[debug]0x4b401000  0x4b4853c2  Yes (*)     C:\WINDOWS\system32\msftedit.dll
[debug]0x6bd81000  0x6bdbd310  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\abbreviations.dll
[debug]0x712c1000  0x7139e8cc  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\astyle.dll
[debug]0x64381000  0x643b1c7c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\autosave.dll
[debug]0x6fc01000  0x6fcaf158  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\AutoVersioning.dll
[debug]0x6f741000  0x6f795d54  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\BrowseTracker.dll
[debug]0x6e141000  0x6e18c86c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\byogames.dll
[debug]0x6ca41000  0x6ca73f64  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\cb_koders.dll
[debug]0x64b81000  0x64bab628  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\Cccc.dll
[debug]0x6af01000  0x6af3c320  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\classwizard.dll
[debug]0x65e81000  0x65fef374  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\codecompletion.dll
[debug]0x67f01000  0x67fdc8ec  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\codesnippets.dll
[debug]0x69f01000  0x69f873c8  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\codestat.dll
[debug]0x03581000  0x036a802c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\compiler.dll
[debug]0x62841000  0x6286a56c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\copystrings.dll
[debug]0x6c081000  0x6c0b8380  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\CppCheck.dll
[debug]0x6f201000  0x6f2852a0  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\Cscope.dll
[debug]0x6d881000  0x6d965e50  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\debugger.dll
[debug]0x649c1000  0x649f8640  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\defaultmimehandler.dll
[debug]0x6fac1000  0x6fb16be0  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\devpakupdater.dll
[debug]0x6c541000  0x6c5c3d44  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\DoxyBlocks.dll
[debug]0x674c1000  0x674fd9b4  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\DragScroll.dll
[debug]0x020b1000  0x020e502c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\EditorConfig.dll
[debug]0x67681000  0x676bf790  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\EditorTweaks.dll
[debug]0x6a701000  0x6a73d5c8  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\envvars.dll
[debug]0x657c1000  0x65a0b178  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\Exporter.dll
[debug]0x63081000  0x6316bc40  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\FileManager.dll
[debug]0x6b141000  0x6b2d4710  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\FortranProject.dll
[debug]0x036b1000  0x0375af4c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\headerfixup.dll
[debug]0x03761000  0x03861cd4  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\help_plugin.dll
[debug]0x7e4b1000  0x7e538bee  Yes (*)     C:\WINDOWS\system32\hhctrl.ocx
[debug]0x62e01000  0x62ef0a24  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\HexEditor.dll
[debug]0x68d81000  0x68db8324  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\IncrementalSearch.dll
[debug]0x03871000  0x03918774  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\keybinder.dll
[debug]0x68001000  0x680ea334  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\lib_finder.dll
[debug]0x03921000  0x0399a990  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxflatnotebook.dll
[debug]0x70201000  0x7022b740  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\MouseSap.dll
[debug]0x64801000  0x648f5d1c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\NassiShneiderman.dll
[debug]0x039a1000  0x039d7120  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\OccurrencesHighlighting.dll
[debug]0x69041000  0x6906c75c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\openfileslist.dll
[debug]0x6edc1000  0x6ee4a6d4  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\Profiler.dll
[debug]0x705c1000  0x70602be0  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\ProjectOptionsManipulator.dll
[debug]0x70501000  0x70556274  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\projectsimporter.dll
[debug]0x69641000  0x69670ad0  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\RegExTestbed.dll
[debug]0x039e1000  0x03a1515c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\ReopenEditor.dll
[debug]0x6a0c1000  0x6a0ea578  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\rndgen.dll
[debug]0x63c01000  0x63c70bd0  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\scriptedwizard.dll
[debug]0x6a981000  0x6a9ae9b4  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentCpp.dll
[debug]0x64e41000  0x64e69560  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentFortran.dll
[debug]0x68d41000  0x68d6b6a8  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentHDL.dll
[debug]0x61501000  0x61529500  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentLua.dll
[debug]0x6ba41000  0x6ba6954c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentPascal.dll
[debug]0x68501000  0x68529508  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentPython.dll
[debug]0x03a21000  0x03a4a5dc  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SmartIndentXML.dll
[debug]0x03a51000  0x03b59894  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SpellChecker.dll
[debug]0x6e281000  0x6e2bc544  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\SymTab.dll
[debug]0x69d41000  0x69dac528  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\ThreadSearch.dll
[debug]0x638c1000  0x639003fc  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxcustombutton.dll
[debug]0x6bac1000  0x6bb58400  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\todo.dll
[debug]0x03b61000  0x03bbe074  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\ToolsPlus.dll
[debug]0x03bc1000  0x03be8478  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\wxsmith.dll
[debug]0x66f41000  0x672da5e4  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxsmithlib.dll
[debug]0x6ab41000  0x6abc1164  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\wxSmithAui.dll
[debug]0x04851000  0x049a7844  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\wxSmithContribItems.dll
[debug]0x6da81000  0x6dad6210  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxchartctrl.dll
[debug]0x66441000  0x66473c30  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wximagepanel.dll
[debug]0x6ed41000  0x6eda2c8c  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxkwic.dll
[debug]0x70c01000  0x70c5d0a8  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxled.dll
[debug]0x049b1000  0x04a5b094  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxmathplot.dll
[debug]0x6f3c1000  0x6f3fb210  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxspeedbutton.dll
[debug]0x04a61000  0x04ab70d8  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxtreelist.dll
[debug]0x62301000  0x6232b604  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\share\CodeBlocks\plugins\xpmanifest.dll
[debug]0x76381000  0x7638403c  Yes (*)     C:\WINDOWS\system32\msimg32.dll
[debug](*): Shared library is missing debugging information.
...

Oh, but I see:
Code
0x6cc41000  0x6d3dcdc8  Yes         E:\code\cb\16.01\codeblocks-16.01-nosetup\wxmsw28u_gcc_cb.dll
There is no * mark, and we have "debug" information in the "wxmsw28u_gcc_cb.dll"? Did you locally strip this dll in your computer? This may destroy the dll if the "strip" command has some issue. (I remember the exchdl.dll has such issue, so we can't strip on it)
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 01, 2016, 07:46:57 am
Hi, Morten, I guess this is an GCC issue comes from TDM's GCC. I just have those test environment:
1, I have a wx 2.8 release which is built by "MinGW-Build 4.8.1 dw2" (Note MinGW-Build 4.8.1 comes from MinGW-W64 project)
2, I build C::B against this wx 2.8, but I build it with "MinGW-Build 4.9. dw2".
3, I can debug C::B under my build GDB(2016-01-30) without any issue.

This is what I get when debugging the above settings:
Code
> info shared

[debug]> info shared
[debug]From        To          Syms Read   Shared Object Library
[debug]0x7c901000  0x7c9b1ee0  Yes (*)     C:\WINDOWS\system32\ntdll.dll
[debug]0x7c801000  0x7c8f5cd8  Yes (*)     C:\WINDOWS\system32\kernel32.dll
[debug]0x617c1000  0x61db59d0  Yes         F:\cb_sf_git\trunk\src\devel\codeblocks.dll
[debug]0x6e941000  0x6e9637bc  Yes (*)     E:\code\gcc\i686-4.9.2-release-posix-dwarf-rt_v3-rev1\mingw32\bin\libgcc_s_dw2-1.dll
[debug]0x77c11000  0x77c67d74  Yes (*)     C:\WINDOWS\system32\msvcrt.dll
[debug]0x64941000  0x64953584  Yes (*)     E:\code\gcc\i686-4.9.2-release-posix-dwarf-rt_v3-rev1\mingw32\bin\libwinpthread-1.dll
[debug]0x77f11000  0x77f58878  Yes (*)     C:\WINDOWS\system32\gdi32.dll
[debug]0x7e411000  0x7e4a0de4  Yes (*)     C:\WINDOWS\system32\user32.dll
[debug]0x6fc41000  0x6fd40f14  Yes (*)     E:\code\gcc\i686-4.9.2-release-posix-dwarf-rt_v3-rev1\mingw32\bin\libstdc++-6.dll
[debug]0x010f1000  0x017b2e84  Yes         E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]0x77dd1000  0x77e6aaf8  Yes (*)     C:\WINDOWS\system32\advapi32.dll
[debug]0x77e71000  0x77f02554  Yes (*)     C:\WINDOWS\system32\rpcrt4.dll
[debug]0x77fe1000  0x77ff0888  Yes (*)     C:\WINDOWS\system32\secur32.dll
[debug]0x5d091000  0x5d12907c  Yes (*)     C:\WINDOWS\system32\comctl32.dll
[debug]0x763b1000  0x763f84dc  Yes (*)     C:\WINDOWS\system32\comdlg32.dll
[debug]0x7c9c1000  0x7d1d6510  Yes (*)     C:\WINDOWS\system32\shell32.dll
[debug]0x77f61000  0x77fd59d4  Yes (*)     C:\WINDOWS\system32\shlwapi.dll
[debug]0x774e1000  0x7761d110  Yes (*)     C:\WINDOWS\system32\ole32.dll
[debug]0x77121000  0x771aa42c  Yes (*)     C:\WINDOWS\system32\oleaut32.dll
[debug]0x76b41000  0x76b6c8b4  Yes (*)     C:\WINDOWS\system32\winmm.dll
[debug]0x73001000  0x7302551c  Yes (*)     C:\WINDOWS\system32\winspool.drv
[debug]0x71ad1000  0x71ad804c  Yes (*)     C:\WINDOWS\system32\wsock32.dll
[debug]0x71ab1000  0x71ac6dc8  Yes (*)     C:\WINDOWS\system32\ws2_32.dll
[debug]0x71aa1000  0x71aa7320  Yes (*)     C:\WINDOWS\system32\ws2help.dll
[debug]0x6e441000  0x6e4e4260  Yes         F:\cb_sf_git\trunk\src\devel\wxpropgrid.dll
[debug]0x76781000  0x767881cc  Yes (*)     C:\WINDOWS\system32\shfolder.dll
[debug]0x66e41000  0x66e4c3d0  Yes (*)     F:\cb_sf_git\trunk\src\devel\exchndl.dll
[debug]0x61541000  0x6157b2fc  Yes (*)     F:\cb_sf_git\trunk\src\devel\mgwhelp.dll
[debug]0x03001000  0x03148ce4  Yes (*)     F:\cb_sf_git\trunk\src\devel\dbghelp.dll
[debug]0x76bf1000  0x76bfa3c4  Yes (*)     C:\WINDOWS\system32\psapi.dll
[debug]0x77c01000  0x77c07300  Yes (*)     C:\WINDOWS\system32\version.dll
[debug]0x76391000  0x763acc6c  Yes (*)     C:\WINDOWS\system32\imm32.dll
[debug]0x019b1000  0x019b828e  Yes (*)     C:\WINDOWS\system32\lpk.dll
[debug]0x74d91000  0x74dfa696  Yes (*)     C:\WINDOWS\system32\usp10.dll
[debug]0x773d1000  0x774d2e2c  Yes (*)     C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll
[debug]0x74721000  0x7476bc4c  Yes (*)     C:\WINDOWS\system32\MSCTF.dll
[debug]0x755c1000  0x755edba0  Yes (*)     C:\WINDOWS\system32\MSCTFIME.IME
[debug]0x02611000  0x028d4448  Yes (*)     C:\WINDOWS\system32\xpsp2res.dll
[debug]0x4b401000  0x4b4853c2  Yes (*)     C:\WINDOWS\system32\msftedit.dll
[debug]0x6bd81000  0x6bd9fde8  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\abbreviations.dll
[debug]0x712c1000  0x71329354  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\astyle.dll
[debug]0x64381000  0x64395ae0  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\autosave.dll
[debug]0x6af01000  0x6af20fe0  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\classwizard.dll
[debug]0x65e81000  0x65fb4810  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\codecompletion.dll
[debug]0x64b01000  0x64baf2f4  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\compiler.dll
[debug]0x6d881000  0x6d904160  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\debugger.dll
[debug]0x649c1000  0x649dc300  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\defaultmimehandler.dll
[debug]0x6cc41000  0x6cc61f20  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\OccurrencesHighlighting.dll
[debug]0x69041000  0x69052640  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\openfileslist.dll
[debug]0x70501000  0x705336fc  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\projectsimporter.dll
[debug]0x04671000  0x046bc914  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\scriptedwizard.dll
[debug]0x6bac1000  0x6baeeb6c  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\todo.dll
[debug]0x04911000  0x0491e4cc  Yes         F:\cb_sf_git\trunk\src\devel\share\CodeBlocks\plugins\xpmanifest.dll
[debug]0x76381000  0x7638403c  Yes (*)     C:\WINDOWS\system32\msimg32.dll
[debug](*): Shared library is missing debugging information.

Look, it still have the similar line:

Code
0x010f1000  0x017b2e84  Yes         E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll

So, I believe your "wxmsw28u_gcc_custom.dll" file has modified(stripped) after build.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 01, 2016, 07:59:18 am
OK, my guess is not correct. Here is my further test:
Code

E:\code\cb\16.01\codeblocks-16.01-nosetup\share>cd ..

E:\code\cb\16.01\codeblocks-16.01-nosetup>which strip
E:\code\common_bin\strip.EXE

E:\code\cb\16.01\codeblocks-16.01-nosetup>strip wxmsw28u_gcc_cb.dll

E:\code\cb\16.01\codeblocks-16.01-nosetup>
I just stip the debug info on the wx dll, and debug codeblocks.exe again. No issue here, and Here is the result:

Code
> info shared

[debug]> info shared
[debug]From        To          Syms Read   Shared Object Library
[debug]0x7c901000  0x7c9b1ee0  Yes (*)     C:\WINDOWS\system32\ntdll.dll
[debug]0x7c801000  0x7c8f5cd8  Yes (*)     C:\WINDOWS\system32\kernel32.dll
[debug]0x5d091000  0x5d12907c  Yes (*)     C:\WINDOWS\system32\comctl32.dll
[debug]0x77dd1000  0x77e6aaf8  Yes (*)     C:\WINDOWS\system32\advapi32.dll
[debug]0x77e71000  0x77f02554  Yes (*)     C:\WINDOWS\system32\rpcrt4.dll
[debug]0x77fe1000  0x77ff0888  Yes (*)     C:\WINDOWS\system32\secur32.dll
[debug]0x77f11000  0x77f58878  Yes (*)     C:\WINDOWS\system32\gdi32.dll
[debug]0x7e411000  0x7e4a0de4  Yes (*)     C:\WINDOWS\system32\user32.dll
[debug]0x77c11000  0x77c67d74  Yes (*)     C:\WINDOWS\system32\msvcrt.dll
[debug]0x7c9c1000  0x7d1d6510  Yes (*)     C:\WINDOWS\system32\shell32.dll
[debug]0x77f61000  0x77fd59d4  Yes (*)     C:\WINDOWS\system32\shlwapi.dll
[debug]0x76781000  0x767881cc  Yes (*)     C:\WINDOWS\system32\shfolder.dll
[debug]0x6cc41000  0x6d3dcdc8  Yes (*)     E:\code\cb\16.01\codeblocks-16.01-nosetup\wxmsw28u_gcc_cb.dll
[debug]0x763b1000  0x763f84dc  Yes (*)     C:\WINDOWS\system32\comdlg32.dll
[debug]0x774e1000  0x7761d110  Yes (*)     C:\WINDOWS\system32\ole32.dll
[debug]0x77121000  0x771aa42c  Yes (*)     C:\WINDOWS\system32\oleaut32.dll
[debug]0x76b41000  0x76b6c8b4  Yes (*)     C:\WINDOWS\system32\winmm.dll
[debug]0x73001000  0x7302551c  Yes (*)     C:\WINDOWS\system32\winspool.drv
[debug]0x71ad1000  0x71ad804c  Yes (*)     C:\WINDOWS\system32\wsock32.dll
...

Look, there is a "*" mark on the wxmsw28u_gcc_cb.dll, and still I don't see any error here.

EDIT:
Please clean up your PATH, and make sure you have 32 bit 2.7.x python installed. :)

Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on February 01, 2016, 07:59:25 pm
My setup is TDM/MinGW 5.1.0. I compiled wx28 and C::B with that.
My guess still is, that the debugger is wrong. I'll explain, why:
* I've checked my PATH several times, its correct
* I even override all PATH settings in C::B using the EnvVars plugin

In all cases it works just fine with any previous release of gdb.
It fails with GDM/TDM (of 5.1.0 distro) and your 2016' gdb.

All GDB use the very same Python (2.7, 32 bit) environment.

Because of that what other than the GDB should be the reason? Do you understand what this GDB error message actually means?
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 03, 2016, 06:57:20 am
My setup is TDM/MinGW 5.1.0. I compiled wx28 and C::B with that.
My guess still is, that the debugger is wrong. I'll explain, why:
* I've checked my PATH several times, its correct
* I even override all PATH settings in C::B using the EnvVars plugin

In all cases it works just fine with any previous release of gdb.
It fails with GDM/TDM (of 5.1.0 distro) and your 2016' gdb.

All GDB use the very same Python (2.7, 32 bit) environment.

Because of that what other than the GDB should be the reason? Do you understand what this GDB error message actually means?
I don't know the error message means, maybe, I need to debug the GDB(debug GDB under GDB), but I can't reproduce on my WinXP.


Today, I just did the test on a Win7 64bit computer. GDB works just fine when loading the C::B. It is very simple to do the test.

1, download a 32 bit python installer(2.7.11), and install it.
2, download my gdb achieve, and unzip it
3, download the C::B 16.01 non-setup zip file, and unzip it.
4, copy the installed python files to the GDB's bin folder
5, start cmd
6, just run "gdb.exe E:/cb1601/CBlauncher.exe"
7, enter "r" to start the C::B.
8, I see C::B 16.01 correctly opened, and GDB does not show any error.

I'm not sure what is your system, I guess your system has some issues.
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: MortenMacFly on February 03, 2016, 07:46:30 am
4, copy the installed python files to the GDB's bin folder
Do you really mean all the files (and sub-folders)? I only copied the DLL.

So its basically a Python with GDB then, right?
Title: Re: [OT] unofficial MinGW GDB gdb with python released
Post by: ollydbg on February 03, 2016, 07:58:51 am
4, copy the installed python files to the GDB's bin folder
Do you really mean all the files (and sub-folders)? I only copied the DLL.
I personally copy all the files and sub-folders of the installed python to GDB's bin folder.

Quote
So its basically a Python with GDB then, right?
What does this sentence means?