'Cannot find bounds of current function' when stepping with GDB 7.6 under OS X 10.6 / LLVM GCC 4.2
This post was updated on .
Hello. I'm porting a wxWidgets-based app towards Mac. For this, my dev station is under OS X 10.6 Snow Leopard with the Xcode 4.2 tools (but I'm using Codeblocks as IDE). I built wxWidgets 3.0.0 and my own project using the Apple flavor of GCC (aka. LLVM GCC 4.2), indicating arch i386. My problem is about debugging : to be able to plug a pretty printer for seeing the wxWidgets structures (e.g. wxString), I need a Python-enabled gdb, and the one provided by Apple in the Xcode tools is not. So, I've taken a try with FSF gdb 7.6 as per http://sourceware.org/gdb/wiki/BuildingOnDarwin, but I experience the impossibility to go step by step. Not talking about IDE, but launching gdb from the command line, the first breakpoint is honored, but using the "n" command to execute one step at a time, I get this error : "cannot find bounds of current function". Since the Apple gdb is still under /usr/bin/, I call the FSF gdb 7.6 with its absolute path (tried with an in-place use and with make install under /usr/local/bin and it gives the same result/error). Of course, at this step not any pretty printer Python script is involved (it will be the next stage if I solve my current issue). I tried to rebuild my project passing an explicit "-ggdb" option rather than the implicit "-g", but it doesn't change anything (same error during stepping). So, what to do ? Do you have an idea about the reason why ? Is it because of incompatible debug info, an issue about arch, a too big gap between the LLVM GCC 4.2 and FSF GDB 7.6... ? I need your lighted advice for sure...
In addition to the error I told about, at the same time, hitting the "n" command, I get something like this too :
0x00003045 in ?? ()
So, the question is maybe : What FSF gdb version should I use to debug a i386 DEBUG build coming from the LLVM GCC 4.2 shipped with Xcode 4.2 under OS X 10.6 (and I have OS X 10.8 with Xcode 4.6 too, but didn't installed my dev environment in full under this station yet) ?
> What I get could look like what expressed in this thread :
> http://sourceware-org.1504.n7.nabble.com/gdb-can-not-debug-hello-world-in-mac-os-x-td107600.html >
> In addition to the error I told about, at the same time, hitting the "n"
> command, I get something like this too :
> (gdb) n
> 0x00003045 in ?? ()
> So, the question is maybe : What FSF gdb version should I use to debug a
> i386 DEBUG build coming from the LLVM GCC 4.2 shipped with Xcode 4.2 under
> OS X 10.6 (and I have OS X 10.8 with Xcode 4.6 too, but didn't installed my
> dev environment in full under this station yet) ?
I am almost sure that FSF gdb doesn't support binaries produced by recent version of
LLVM shipped by xcode. They use compact unwinding, which isn't handled by gdb.
This is on my todo list, but not that urgent because FSF gcc doesn't emit them (it
passes -no_compact_unwind to ld).
> Thanks for this informed info, Tristan. I keep track that it's on your TODO
> list ;)
> And I suppose this is not configurable by a switch/flag/option at LLVM GCC
> 4.2 side (to produce a FSF gdb compliant binaries of course) ?
This is a linker issue: try to link with -Wl,-no_compact_unwind (IIRC).
> Also, another question for another approach : Is it possible to go with FSF
> GCC (ie. not the Apple-LLVM one) under OS X ?
Re: 'Cannot find bounds of current function' when stepping with GDB 7.6 under OS X 10.6 / LLVM GCC 4.2
No luck ! I've tried, rebuilding both the DEBUG build of my project and the underlying static wxWidgets DEBUG build too, adding "-Wl,-no_compact_unwind" (without quotes) in the IDE's linker options for my project and in the LDFLAGS for wxWidgets (building it from command line)... And same result :(
Here is a typical gdb session showing the concerned behavior :
Breakpoint 1, MyApp::OnInit (this=0x8010a00) at MyApp.cpp:162
0x00ab2a34 in ?? ()
Cannot find bounds of current function
So, did I missed a point ? What can I do other ?
And for the other way, using full FSF GCC/GDB, not tried yet. But I'll do it.