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-30New 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-23gdb2014-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-14A 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-09New 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.next.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-08New 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-04gdb2013-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.
set filename-display absolute
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-19gdb2012-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-22gdb2012-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:
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-16gdb2012-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.next.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.next.codeblocks.org/index.php/topic,14792.msg99575.html#msg99575).
2012-01-19HAPPY 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 releasePre-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.next.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-09Update 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-10To solve the problem I stated in load gdb's own python script support (http://forums.next.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-04NOTE: 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.next.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.next.codeblocks.org/index.php/topic,15074.msg100825.html#msg100825).
2011-06-06gdb-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-02new version: gdb-7.2.50.20110401.7z (http://qp-gcc.googlecode.com/files/gdb-7.2.50.20110401.7z)
2011-01-10build 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-13build 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.next.codeblocks.org/index.php?action=profile;u=12871)'s help!!!
2010-09-05since 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-09The 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-24The 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.next.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 GDBGDB 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)
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:
> 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:
:(
Quote from: ollydbg on October 08, 2009, 08:35:44 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:
> 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.
Will test on arch linux today, hope it works
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.
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]
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.
#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
Quote from: 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.
#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!
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.
EditYou can view the thread under this webpage:
http://news.gmane.org/gmane.comp.gnu.mingw.user
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]
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.
Quote from: 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]
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.
:(
I have the same problem (execution doesn't stop at breakpoint during debug) with gdb 6.8.
Here is the gdb log
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.
@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.
Quote from: ollydbg on October 08, 2009, 02:02:55 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.
Quote from: 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.
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.
Quote from: MortenMacFly on October 08, 2009, 02:51:04 PM
Quote from: ollydbg on October 08, 2009, 02:02:55 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:
>>>>>>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
Quote from: MortenMacFly on October 08, 2009, 02:51:04 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?
Quote from: oBFusCATed on October 08, 2009, 03:47:56 PM
Quote from: MortenMacFly on October 08, 2009, 02:51:04 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. :(
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
main should be in src/src/main.cpp not in the console runner :)
Quote from: ollydbg on October 08, 2009, 03:54:28 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. ;-)
Quote from: oBFusCATed on October 08, 2009, 04:48:34 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:
EditBut 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
Quote from: ollydbg on October 08, 2009, 05:01:51 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
@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:
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.
>>>>>>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 :(
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":#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: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: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]
Can you try a nightly build?
Quote from: oBFusCATed on October 09, 2009, 07:54:10 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.
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:
@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:
>>>>>>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.
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.
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:
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:
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.
How is C::B attempting to 'pause' gdb.exe?
Quote from: ironhead on October 10, 2009, 01:47:58 PM
How is C::B attempting to 'pause' gdb.exe?
Read the source code of the Break() function. You will see it.
In the 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 :
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.next.codeblocks.org/index.php?topic=8577.0
or
http://www.nabble.com/GDB-Ctrl-C-Break-td1782635.html
or
http://forums.next.codeblocks.org/index.php/topic,7964.msg59677.html#msg59677
As posted in this message:
http://forums.next.codeblocks.org/index.php/topic,7964.msg61123.html#msg61123
Wouldn't sending a:
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?
Quote from: ironhead on October 10, 2009, 04:36:04 PM
As posted in this message:
http://forums.next.codeblocks.org/index.php/topic,7964.msg61123.html#msg61123
Wouldn't sending a:
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.
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]
Quote from: ollydbg on October 11, 2009, 03:40:42 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 ...
Quote from: nanyu on October 11, 2009, 06:04:26 AM
Quote from: ollydbg on October 11, 2009, 03:40:42 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. :(
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.
Quote from: 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]
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:
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.
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.next.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.
Yes it is not done and I'm not sure if it can be done easily...
Quote from: 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.
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
I just find more bugs of GDB.
Follow the steps
Quote from: ollydbg on October 12, 2009, 01:25:30 AM
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:
> 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:
:(
You can try like this:
file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll
Quote from: nenin on October 12, 2009, 11:47:04 AM
You can try like this:
file F:/cb_svn/src/devel/share/CodeBlocks/plugins/codecompletion.dll
Thanks, but it still doesn't work.
>>>>>>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.
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.next.codeblocks.org/index.php/topic,11301.msg77156.html#msg77156
Another question, can somebody explain that what's these warning means?
> 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.
Ollydbg: try asking the gdb devs directly (#gdb at freenode will be the fastest).
This seems to be a gdb problem...
Quote from: 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...
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.
Quote from: ollydbg on October 14, 2009, 09:48:07 AM
Quote from: 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...
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.
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.next.codeblocks.org/index.php/topic,11301.msg77156.html#msg77156
Applied in trunk.
Quote from: ironhead on October 14, 2009, 06:26:23 PM
Quote from: ollydbg on October 14, 2009, 09:48:07 AM
Quote from: 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...
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. :(
Quote from: ollydbg on October 15, 2009, 02:37:18 AM
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).
Quote from: olelukoie on October 20, 2009, 04:21:31 PM
Quote from: ollydbg on October 15, 2009, 02:37:18 AM
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
Quote from: 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.
The GDB 7.02 can not work well with my project (a exe with named Demo2 and a dll named Tutorial04):
> 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 :
/*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
Quote from: nanyu on November 17, 2009, 03:12:58 AM
Quote from: 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.
The GDB 7.02 can not work well with my project (a exe with named Demo2 and a dll named Tutorial04):
> 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.
Quote from: ollydbg on November 17, 2009, 03:20:43 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.
#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 :
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.
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.next.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...
Quote from: 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.next.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!
Just a reminder:
In the MinGW mail list:
QuoteFrom: Chris Sutcliffe <ir0nh34d@...>
Subject: GDB 7.0.1
Newsgroups: gmane.comp.gnu.mingw.user
Date: 2010-01-07 19:07:37 GMT (5 days, 10 hours and 11 minutes ago)
I've released GDB 7.0.1 for MinGW. This binary is built from vanilla
GNU GDB sources.
http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.1/gdb-7.0.1-mingw32-bin.tar.gz/download
This time around I've packaged it without the static libraries
(libbfd, libopcodes, libiberty) so as to not conflict with binutils.
Please direct any questions / comments to this mailing list.
Enjoy!
Chris
one problem still exist. too many gdb warning when debugging C::B (http://forums.next.codeblocks.org/index.php/topic,11301.msg77274.html#msg77274)
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.
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
Quote from: ironhead on February 07, 2010, 03:16:07 PM
Just a heads up, I've release a new GDB snapshot:
http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download
This release includes a fix for the symtab / psymtab warnings that will be part of the GDB 7.1 release when it becomes official.
Thanks Chris. I've been using it since you made this announcement in MinGW mailing list. This build is much better than previous gdb 7 versions. :)
ironhead:
Does this release has python scripting enabled?
If it is not enabled can you tell me why?
Quote from: oBFusCATed on February 07, 2010, 06:52:20 PM
ironhead:
Does this release has python scripting enabled?
If it is not enabled can you tell me why?
Python scripting is not enabled. To be honest I haven't looked in to adding it (I don't use it myself), but I'll take a look at what's involved in adding the support this coming week.
thanks chris for your hard work. I will tested tonight.
EditIt works fine, and the symtab/psymtab bug is fixed. Thanks very much!!
Quote from: ironhead on February 07, 2010, 03:16:07 PM
Hi All,
Just a heads up, I've release a new GDB snapshot:
http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download
This release includes a fix for the symtab / psymtab warnings that will be part of the GDB 7.1 release when it becomes official.
Cheers!
Chris
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?
Quote from: JZ on February 09, 2010, 06:02:45 AM
Do I need to separately install GDB?
Depends on your gcc installation.
But with this error-message the answer is most likely yes.
For a download see the link in one of the previous posts.
To check whether it is set up correctly, look into "Settings -> Compiler and debugger -> Global compiler settings -> [your compiler] -> Toolchain executables" .
@Chris Sutcliffe
I find the 7.0.50 version of gdb didn't work correctly.
when I try to view a wxString value in Codeblocks, it takes a lot of time.
> whatis m_Buffer
type = wxString
>>>>>>cb_gdb:
> output /c m_Buffer.m_pchData[0]@((wxStringData*)m_Buffer.m_pchData - 1)->nDataLength
{116 't', 101 'e', 115 's', 116 't', 46 '.', 99 'c', 112 'p', 112 'p'}>>>>>>cb_gdb:
When the codeblocks send the command : output xxxxx to gdb, it takes several (more than 10s) to return the string value.
Quote from: ollydbg on February 11, 2010, 03:33:38 PM
@Chris Sutcliffe
I find the 7.0.50 version of gdb didn't work correctly.
when I try to view a wxString value in Codeblocks, it takes a lot of time.
> whatis m_Buffer
type = wxString
>>>>>>cb_gdb:
> output /c m_Buffer.m_pchData[0]@((wxStringData*)m_Buffer.m_pchData - 1)->nDataLength
{116 't', 101 'e', 115 's', 116 't', 46 '.', 99 'c', 112 'p', 112 'p'}>>>>>>cb_gdb:
When the codeblocks send the command : output xxxxx to gdb, it takes several (more than 10s) to return the string value.
What happens, if you debug from commandline ?
Quote from: jens on February 11, 2010, 07:55:55 PM
What happens, if you debug from commandline ?
Or if you put the command in the "Command:" text-control and execute it (without running of C::B's gdb-parser) ?
Do you use any debugger related patches or clean sources from trunk.
I just tested it with gdb 7.0.50 as cross-debugger for a wxMSW app on my linux-box and the output occurs immediately after the command is sent to gdb (from inside the program or from the textcontrol).
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.
@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 )
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.
Quote from: 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.
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.
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.
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. ;)
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... :(
@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
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?
Quote from: ollydbg on February 23, 2010, 07:27:59 AMDid 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.
@ironhead:
Thanks, I posted a message in gdb maillist, also a bug report in the GDB Bugzilla.
@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:
QuoteThis 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 :(
@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!
Quote from: ollydbg on February 27, 2010, 04:27:26 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.
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?
Quote from: 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
You can use either. The MinGW sources are the same as the official sources, just renamed.
QuoteDid 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.
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
./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:
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.
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:
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
--with-libexpat
??
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
./configure --with-expat
in this folder... :D
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:
./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:
../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
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.
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.
Ah, great... time to test gdb_mi with this :)
Quote from: ollydbg on March 19, 2010, 04:01:03 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:
Just a reminder:
Today, Chirs has announced an offcial mingw gdb 7.1 in the mingw maillist:
QuoteI'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.next.codeblocks.org/index.php/topic,11301.msg77273.html#msg77273)
Thanks.
Quote from: Loaden on March 19, 2010, 11:30:04 AM
Quote from: ollydbg on March 19, 2010, 04:01:03 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.
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
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]
Here is the test 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:
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.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
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.
Quote from: 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.
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)
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.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
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!!!
The build steps( corss build windows gdb from linux) are list here in
http://code.google.com/p/qp-gcc/wiki/CrossbuildGDB
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.next.codeblocks.org/index.php?action=profile;u=12871)'s help!!!
strange, my last post
Quote2010-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.next.codeblocks.org/index.php?action=profile;u=12871)'s help!!!
was list in the Recent Posts (http://forums.next.codeblocks.org/index.php?action=recent;start=10)
but when I click the link :
http://forums.next.codeblocks.org/index.php/topic,11301.msg93230.html#msg93230
I still can't see that post :(
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).
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.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
thanks.
ollydbg
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?
What is the charset of your string?
Have you tried the python pretty printers for wxWidgets?
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
FYI:
xunxun1982 (http://forums.next.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
FYI:
xunxun1982 (http://forums.next.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/)
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
updated the gdb cvs mingw build on 2011-06-04
see [OT] unoffcial MinGW GDB gdb with python released (http://forums.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.
update the GDB binary to 20110802 with some Windows Patches.
See [OT] unofficial MinGW GDB gdb with python released (http://forums.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.
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.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for some details.
Sorry for the inconvenience.
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!
Quote from: 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!
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.
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?..
Quote from: 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?..
Ollydbg doesn't have 64bit OS...
Quote from: 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?..
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.
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.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details. :D
Thank you anyhow! I'll see what I can do.
Quote from: 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.next.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.
Quote from: nenin on August 17, 2011, 05:34:52 PM
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:
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.
Quote from: ollydbg on August 18, 2011, 03:16:55 AM
Did you mean like below:
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.
Quote from: nenin on August 18, 2011, 12:37:31 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.
Quote from: ollydbg on August 18, 2011, 02:57:03 PM
Quote from: nenin on August 18, 2011, 12:37:31 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.
I found other issue. This declaration:
const static std::string apms[5]={"&","<",">",""","'"};
kills GDB.
Quote from: nenin on August 27, 2011, 05:29:02 PM
I found other issue. This declaration:
const static std::string apms[5]={"&","<",">",""","'"};
kills GDB.
I just test it and works here.(WinXP, MinGW GCC 4.6.1)
see the debug log:
Quote
> p apms
$1 = {"&", "<", ">", """, "'"}
Quote from: ollydbg on August 28, 2011, 03:07:12 AM
see the debug log:
Quote
> p apms
$1 = {"&", "<", ">", """, "'"}
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
Quote from: nenin on August 31, 2011, 06:56:18 PM
Quote from: ollydbg on August 28, 2011, 03:07:12 AM
see the debug log:
Quote
> p apms
$1 = {"&", "<", ">", """, "'"}
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).
Quote from: ollydbg on September 01, 2011, 04:58:48 AM
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?
If you turn off CC it is very stable :)
If you use CC there are some crashes...
Quote from: oBFusCATed on September 01, 2011, 04:07:42 PM
If you turn of CC it is very stable :)
If you use CC there are some crashes...
What is "CC"? :?
Code completion.
Quote from: oBFusCATed on September 02, 2011, 02:04:20 PM
Code completion.
I forgot about it since return from Delphi to C++. :D
Quote from: ollydbg on September 01, 2011, 04:58:48 AM
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.
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.next.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)
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.
Bump to GDB cvs 2012-05-22, see the first post for download link and more information. :)
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 :))
Bump to gdb cvs 2012-12-15, see the first post: [OT] unofficial MinGW GDB gdb with python released (http://forums.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000)
Bump to 2013-02-04 release, the "filename display format" patch was now already in gdb cvs, see the first post for more information.
Updated to GDB cvs 2013-06-08, see the [OT] unofficial MinGW GDB gdb with python released (http://forums.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details.
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
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.
[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.
> 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.
Quote from: golgepapaz on July 06, 2013, 12:08:21 AM
...
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.next.codeblocks.org/index.php/topic,16772.msg114299.html#msg114299)
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.next.codeblocks.org/index.php/topic,18403.0.html), please see the first page [OT] unofficial MinGW GDB gdb with python released (http://forums.next.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000) for more details. Thanks.
Bump: a new release 2014-01-14 is here. Updated page [OT] unofficial MinGW GDB gdb with python released (http://forums.next.codeblocks.org/index.php/topic,11301.0.html) gives you more details. Thanks.
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).
...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.
Quote from: 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.
I personally build GDB months ago(I have not uploaded yet), I will build and upload the GDB git head this weekend
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.next.codeblocks.org/index.php/topic,11301.0.html) for details.
Quote from: 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.next.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.)
Quote from: 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.next.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?
Quote from: MortenMacFly on January 31, 2016, 05:52:32 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...
You want to see the name of the selected debugger configuration, right?
I think we print the path to the debugger already.
Quote from: oBFusCATed on January 31, 2016, 06:25:05 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. :-(
Quote from: MortenMacFly on January 31, 2016, 07:39:37 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.:)
Quote from: MortenMacFly on January 31, 2016, 07:39:37 PM
Quote from: oBFusCATed on January 31, 2016, 06:25:05 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. :-(
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.
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.
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:
--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:
[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:
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)
Quote from: 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.
This is what I get when debugging the above settings:
> 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:
0x010f1000 0x017b2e84 Yes E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dllSo, I believe your "wxmsw28u_gcc_custom.dll" file has modified(stripped) after build.
OK, my guess is not correct. Here is my further test:
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:
> 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. :)
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?
Quote from: 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?
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.
Quote from: ollydbg on February 03, 2016, 06:57:20 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?
Quote from: MortenMacFly on February 03, 2016, 07:46:30 AM
Quote from: ollydbg on February 03, 2016, 06:57:20 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?