Code::Blocks
April 23, 2014, 08:40:08 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!
 
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: [1] 2 3 4 5 6 ... 11   Go Down
  Send this topic  |  Print  
Author Topic: [OT] unofficial MinGW GDB gdb with python released  (Read 81601 times)
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 3886


Interests on OpenCV and Robotics


WWW
« on: October 08, 2009, 08:21:52 am »

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

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

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

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

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

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

2012-05-22
gdb2012-05-22now build from xunxun's mingw gcc 32bit 4.6.3 release.
Here is the total patch file patch against gdb cvs.
It is linked to python 2.7.3 library, so you need to have python 2.7.3 installed on your system.
To see the full file path on the backtrace command, you need to run the command:
Code:
set backtrace filename-display absolute
See: Jan Kratochvil - Re: [patch] GDB 7.2: new feature for "backtrace" that cuts path to file for more details and other options.


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

This release fix the regression and works OK now.

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


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


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

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

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

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

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

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

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

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

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

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

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

Happy New Year!!!

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

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

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

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

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

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

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

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

« Last Edit: January 29, 2014, 12:29:04 pm by ollydbg » Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 3886


Interests on OpenCV and Robotics


WWW
« Reply #1 on: October 08, 2009, 08:35:44 am »

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

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

So, it's much faster. Cheesy

Edit

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

see the debug log:

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

 Sad
« Last Edit: October 10, 2009, 05:11:57 pm by ollydbg » Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
jens
Administrator
Lives here!
*****
Offline Offline

Posts: 6429



WWW
« Reply #2 on: October 08, 2009, 09:14:17 am »

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

see the debug log:

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

 Sad

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

Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5 & 6] - nightlies : http://rpm.jenslody.de/
oBFusCATed
Developer
Lives here!
*****
Online Online

Posts: 7204


« Reply #3 on: October 08, 2009, 09:48:52 am »

Will test on arch linux today, hope it works
Logged

<debugger plugin maintainer>
(most of the time I ignore long posts)
jens
Administrator
Lives here!
*****
Offline Offline

Posts: 6429



WWW
« Reply #4 on: October 08, 2009, 10:50:59 am »

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

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

Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5 & 6] - nightlies : http://rpm.jenslody.de/
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 3886


Interests on OpenCV and Robotics


WWW
« Reply #5 on: October 08, 2009, 01:21:39 pm »

Here is the full output of the debug log.

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



[attachment deleted by admin]
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
mariocup
Developer
Lives here!
*****
Offline Offline

Posts: 587


« Reply #6 on: October 08, 2009, 01:31:50 pm »

Hi ollydbg,

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

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

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


« Last Edit: October 08, 2009, 01:54:08 pm by mariocup » Logged
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 3886


Interests on OpenCV and Robotics


WWW
« Reply #7 on: October 08, 2009, 01:41:18 pm »

Hi ollydbg,

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

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

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

Thanks.

I will report this issue on the MinGW Mail list.

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

Thanks again!
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 3886


Interests on OpenCV and Robotics


WWW
« Reply #8 on: October 08, 2009, 01:43:49 pm »

In the MinGW maillist. someone said:

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


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

Edit

You can view the thread under this webpage:

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


« Last Edit: October 08, 2009, 01:50:15 pm by ollydbg » Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
killerbot
Administrator
Lives here!
*****
Offline Offline

Posts: 4802


« Reply #9 on: October 08, 2009, 01:50:58 pm »

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

However I also noticed something strange.

Tooltipped during debugging on an std::string (local variable).  [the ..... mean there is more stuff there]
Code:
ContinueDebugEvent .......
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
ContinueDebugEvent ....
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
"Group"
Notice the "Group" at the end, the correct value of the string.

With another string it is ok.
Logged
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 3886


Interests on OpenCV and Robotics


WWW
« Reply #10 on: October 08, 2009, 02:02:55 pm »

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

However I also noticed something strange.

Tooltipped during debugging on an std::string (local variable).  [the ..... mean there is more stuff there]
Code:
ContinueDebugEvent .......
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
ContinueDebugEvent ....
gdb : kernel event for pid= ..... ... code=EXCEPTION_DEBUG_EVENT
"Group"
Notice the "Group" at the end, the correct value of the string.

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

Here is the main step:

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


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

 Sad

Logged

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

Posts: 57


« Reply #11 on: October 08, 2009, 02:27:29 pm »

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

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

Posts: 3886


Interests on OpenCV and Robotics


WWW
« Reply #12 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.
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
MortenMacFly
Administrator
Lives here!
*****
Offline Offline

Posts: 8543



« Reply #13 on: October 08, 2009, 02:51:04 pm »

But could you please test by setting a breakpoint in the codeblocks' source code? this case, it didn't work here.
Works fine, here.
I set a BP in C::B's "main" function -> stops.
While stopped I set a BP in a sub-method that'll be called certainly and hit continue -> stops.

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

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

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
vix
Advanced newcomer
*
Offline Offline

Posts: 57


« Reply #14 on: October 08, 2009, 02:59:38 pm »

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

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

I did some tests with the "Hello World" example: the debugger stops at breakpoint only if the project files and the debugger are in the same unit (both in C: disk), and the path doesn't contain spaces. If I move the project to another unit (Z:\), or to a path with spaces (for example  \Documents and Settings\...) the debugger doesn't stop anymore at the breakpoint.
« Last Edit: October 09, 2009, 01:33:54 pm by vix » Logged
Pages: [1] 2 3 4 5 6 ... 11   Go Up
  Send this topic  |  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!