Possible bug using Code::blocks & GDB on Mac OS X

[tharris997]

First off, let me start by saying C::B is awesome! I've been using it for some time now for a cross-platform project.

Unfortunately, I've encountered some problems debugging on the Mac (debugging works great under XP & Ubuntu). I ran into the "No source file named <blah>" issue, which appears in several threads on the forum. However, I've ruled out the common causes (no debug symbols, -fullname not set, etc.) and dug a little deeper. The issue is actually due to how the C::B debugger plugin passes break command strings to GDB (or an alternate view could be how GDB fails to interpret the strings correctly). C::B passes the source file names along with absolute paths, and for some reason GDB doesn't like those absolute paths and insists that it can't find the files. I tested this outside C::B and can produce the same results from GDB.

E.G.

gdb -nx -fullname -args someprogram
Reading symbols for shared libraries.... done
(gdb) break "/some/long/path/main.cpp:56"
No source file named /some/long/path/main.cpp
(gdb) break "main.cpp:56"
breakpoint 1 at 0x33d8: file main.cpp, line 56

Why GDB isn't interpreting these paths correctly I don't know, but it doesn't. So either the C::B debugger plugin needs an option to pass "flat" filenames with no path or GDB needs to be fixed to interpret the paths correctly (I'll be posting on the GDB forums too  ). Strangely enough, the same commands are passed on the other platforms and GDB doesn't have any problem with the absolute paths there.

FYI, I did try playing with the "Use Full Paths for source files" and "Use Flat Objects" options in the advanced settings, but neither seem to make any difference to the commands GDB is passed. I did find a workaround - Adding directories to the "Additional debugger search dirs". Unfortunately, this has to be done for every single source directory. Not a problem if you only have one source dir, but on large projects that's not the case. You have to add the nested dirs too for any source file you want to debug into. Then GDB can suddenly find them, despite the fact it's being supplied with absolute paths!

I'm more than happy to supply additional info if someone wants to try and fix this.

Cheers!
Tim

[Joerg]

Hi Tim,
I was lucky to hear about your solution.
Unfortunately your workaround doesn't work here under WinXP.
But instead of saying 'file not found' GDB says nothing
and does not set any breakpoint.
This bug (at least under Win an OSX) exists for a long time now.
But the priorities seem to be set different it seems.
:-(

[tharris997]

Hi Tim,
I was lucky to hear about your solution.
Unfortunately your workaround doesn't work here under WinXP.
But instead of saying 'file not found' GDB says nothing
and does not set any breakpoint.
This bug (at least under Win an OSX) exists for a long time now.
But the priorities seem to be set different it seems.
:-(

That's strange, because everything works fine under XP for me and the setups on all my platforms are pretty much identical. Can you post the GDB command log from C:B, please? You'll need to turn on the GDB log - Go to Settings-->Compiler and debugger-->Debugger Settings-->"Display debuggers log". This will show you what C::B is telling GDB to do.

My XP one looks like this:

Command-line: D:\Subversion\trunk\Packages\External\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/win32/debug/game.exe
Working dir : D:\Subversion\trunk\Packages\Local\game\1.00.00\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "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 disassembly-flavor att
>>>>>>cb_gdb:
> cd ./bin/win32/debug
>>>>>>cb_gdb:
> directory D:/Subversion/trunk/Packages/Local/gamecore/1.00.00/
>>>>>>cb_gdb:
> directory D:/Subversion/trunk/Packages/Local/graphics/1.00.00/
>>>>>>cb_gdb:
> directory D:/Subversion/trunk/Packages/Local/memman/1.00.00/
>>>>>>cb_gdb:
> directory D:/Subversion/trunk/Packages/Local/game/1.00.00/
>>>>>>cb_gdb:
> break "D:/Subversion/trunk/Packages/Local/game/1.00.00/src/main.cpp:9"
Breakpoint 1 at 0x40132b: file main.cpp, line 9.   <---- Success!

Whereas OS X looks like this:

Command-line: /usr/bin/gdb -nx -fullname  -quiet -args bin/macos/debug/game
Working dir : /Users/tharris/Subversion/trunk/Packages/Local/game/1.00.00/
> set prompt >>>>>>cb_gdb:
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries ....
. done
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:16:54 GMT 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".
>>>>>>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 disassembly-flavor intel
>>>>>>cb_gdb:
> cd bin/macos/debug
>>>>>>cb_gdb:
> directory  /Users/tharris/Subversion/trunk/Packages/Local/gamecore/1.00.00/
>>>>>>cb_gdb:
> directory  /Users/tharris/Subversion/trunk/Packages/Local/graphics/1.00.00/
>>>>>>cb_gdb:
> directory  /Users/tharris/Subversion/trunk/Packages/Local/memman/1.00.00/
>>>>>>cb_gdb:
> directory /Users/tharris/Subversion/trunk/Packages/Local/game/1.00.00/
>>>>>>cb_gdb:
> break "/Users/tharris/Subversion/trunk/Packages/Local/game/1.00.00/src/main.cpp:9"
No source file named /Users/tharris/Subversion/trunk/Packages/Local/game/1.00.00/src/main.cpp.  <--- Booooo! No file found

The workaround under OS X is to add the source directories one at a time: e.g "directory /Users/tharris/Subversion/trunk/Packages/Local/game/1.00.00/src", but that is going to get more and more timeconsuming/troublesome as my project grows

As you can see, both systems are using GDB 6.3. GDB 6.8 is actually the latest, but since there's no prob on XP I haven't changed it and under OS X I can't get GDB to build because it doesn't support i386-apple-darwin or similar builds - You have to use the GDB supplied with XCode.

Anyway, if you post your log I'll take a look

[rhf]

I don't know if this is related but thought I should bring it to your attention just in case.
http://forums.codeblocks.org/index.php/topic,9295.msg66321.html#msg66321
and tdragon's comments on
https://sourceforge.net/tracker/index.php?func=detail&aid=2145427&group_id=200665&atid=974439

[tharris997]

I don't know if this is related but thought I should bring it to your attention just in case.
http://forums.codeblocks.org/index.php/topic,9295.msg66321.html#msg66321
and tdragon's comments on
https://sourceforge.net/tracker/index.php?func=detail&aid=2145427&group_id=200665&atid=974439

rhf, you've just made my day!

I read the post and re-examined the paths g++ was using. Since my makefiles are setup to call g++ from within the source directories as the projects are being traversed, no source paths are being used (e.g. g++ g++ -c -o C:/somepath/main.o main.cpp). This has no effect under XP & Linux but it's exactly what was stuffing up GDB on OS X! After adding absolute paths to the source files GDB works 

So thanks for pointing me in the right direction.

[Joerg]

Hi,

The workaround under OS X is to add the source directories one at a time: e.g "directory /Users/tharris/Subversion/trunk/Packages/Local/game/1.00.00/src", but that is going to get more and more timeconsuming/troublesome as my project grows

i added all subdirectories as under Project/Properties/'Additional Debugger Search Dirs'
without success:
>>>>>>cb_gdb:
> break "D:/Projekte/icps-sw/src/BackgroundTask.c:630"
No source file named D:/Projekte/icps-sw/src/BackgroundTask.c.
Breakpoint 3 ("D:/Projekte/icps-sw/src/BackgroundTask.c:630) pending.

I tried relative and direct paths.

After adding absolute paths to the source files GDB works

What do you mean by that?
I invoke gcc via makefile, paths are defined therein.
If i look into a list file:

  13                 spi_cs_assert:
  14                 .LFB2:
  15                    .file 1 "../../src/spi.c"

Paths are relative here, but C::B calls GDB with an absolut path.
'Advanced Options' have no effect as you already said.
The sources are lying in a different directory than the makefile.
Anyway, running gdb from command line works.