Problem setting breakpoints for GDB

[sellibitze]

This is my situation: I installed MinGW 3.4.5 on a WinXP box, C::B 8.02 and Boost.Build. When I use the C::B internal build system I have no problems with debugging. Setting breakpoints works perfectly. I recently switched to using Boost.Build. I still want to use C::B for editing and as GDB-Frontend. All seemed to work perfectly. But now I'm unable to set break points and I don't know why.

This is what C::B is showing me in its debugging console:

Building to ensure sources are up-to-date
Build succeeded
Selecting target: 
debug
Adding source dir: C:\xxx\CB-Workspace\altomo\
Adding file: bin\gcc-mingw-3.4.5\debug\link-static\altomo.exe
Starting debugger: 
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.6
No source file named C:/xxx/CB-Workspace/altomo/src/main.cpp.
Breakpoint 1 ("C:/xxx/CB-Workspace/altomo/src/main.cpp:181) pending.

GDB doesn't seem to recognize the source's filename. I verified that all the object files of the debug build contain all the path informations. To be specific the project's root directory (C:/xxx/CB-Workspace/altomo) is recorded as well as the relative path (src/main.cpp) for the translation unit in question. If you look closely at the last line you'll see that there's only a single quotation mark that might have been introduced because xxx is an abbreviation for something with spaces.

If I start GDB manually I'm able to set the breakpoints by specifying the source file in 4 different ways:

(gdb) break main.cpp:181
Breakpoint 1 at 0x40231e: file src/main.cpp, line 181.
(gdb) break src/main.cpp:182
Breakpoint 2 at 0x402331: file src/main.cpp, line 182.
(gdb) break "C:/xxx/CB-Workspace/altomo/src/main.cpp:183"
Breakpoint 3 at 0x40234f: file src/main.cpp, line 183.
(gdb) break "C:/xxx/CB-Workspace/altomo/src/main.cpp:184
Breakpoint 4 at 0x402431: file src/main.cpp, line 184.
(gdb)

(filename, relative path and absolute path with trailing and missing quote)

Do you know why I can't get it to work with C::B? Did I miss something? Is this a bug of some kind?

TIA,
sellibitze

[ollydbg]

One suggestion:
You can open the "full debugger log" to see what the command send to GDB, and what is returned from GDB. There is an option in

Setting -> compiler and debugger settings -> debugger settings -> Display debugger's log.

Also, I personally suggest you could use a more recent Package, like: codeblocks nightly build. and TDM-MinGW GCC 4.4.1.

[sellibitze]

One suggestion:
You can open the "full debugger log" to see what the command send to GDB, and what is returned from GDB.

Thanks. I just tried it. It all looks fine except that setting breakpoints still doesn't work:

Code

:
>>>>>>cb_gdb:
> directory C:/XXX~1/CB-WOR~1/altomo/
>>>>>>cb_gdb:
> break "C:/xxx/CB-Workspace/altomo/src/main.cpp:181"
No source file named C:/xxx/CB-Workspace/altomo/src/main.cpp.
Breakpoint 1 ("C:/xxx/CB-Workspace/altomo/src/main.cpp:181) pending.
>>>>>>cb_gdb:
> run
gdb: win32_init_thread_list
:

Ok, so the break line is exactly the same line I used successfully during the manual GDB session. The problem seems to be with the directory command. If I start GDB manually in the console and use the very same break-line it works. If I use the directory command with the "mangled" DOS name it doesn't work anymore. But when I replace the mangled DOS name with the real one it works again. So, the question is: How do I get C::B to send the "real path" to GDB? I tried adding a new search path for the debugger (via Project properties -> Debugger) but that didn't work. C::B still sends a directory-command with the mangled DOS name. I could try a nighly build, maybe this will help ...

Also, I personally suggest you could use a more recent Package, like: codeblocks nightly build. and TDM-MinGW GCC 4.4.1.

I thought TDM-MinGW had some performance issues (generating slow code) which is why I sticked to MinGW 3.4.5. I don't know whether that is or was true. I'd much rather use a more modern g++ version. Maybe I'll look into TDM-MinGW again...

Edit: Ok, according to TDM site the new version fixed the bug that drastically reduced speed.

[ollydbg]

You can try a nightly build version, because there is a "command input edit control" at the bottom of the debugger panel(also in debugger's log panel), so, you can directly send the GDB command there.

also, TDM-GCC works great, the "slow speed problem" only exist in the first release of TDM-GCC 4.4.1, now, it was already fixed in TDM-GCC 4.4.1-2.