GCC debugger stack trace displays wrong file name

问题:

I am trying to port a fairly large C++ project to using g++ 4.0 on Mac OS X. My project compiles without errors, but I can't get GDB to work properly. When I look at the stack by typing "bt" on the GDB command line, all file names and line numbers displayed are wrong.

For example, according to the GDB stack trace, my main() function is supposed to be in stdexcept from the Mac OS X SDK, which does not make any sense.

What could cause GDB to malfunction so badly? I've already checked for #line and #file statements in my code and made sure that the code only has unix line endings. I've also cleaned and rebuilt the project. I've also tried debugging a Hello World project and that one did not have the same problem.

Could the problem have to do with one of the third party libraries I am linking and the way those are compiled? Or is it something completely different?

Here are two exemplary calls to gcc and ld as executed by Xcode. AFAIK all cpp-files in my project are compiled and linked with the same parameters.

/Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -fpermissive -Wreturn-type -Wunused-variable -DNO_BASS_SOUND -D_DEBUG -DXCODE -D__WXMAC__ -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.4 -gdwarf-2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -c "/Users/adriangrigore/Documents/Gemsweeper Mac/TSDLGameBase.cpp" -o "/Users/adriangrigore/Documents/Gemsweeper Mac/build/Gemsweeper Mac.build/Debug/Gemsweeper Mac.build/Objects-normal/i386/TSDLGameBase.o"

/Developer/usr/bin/g++-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk "-L/Users/adriangrigore/Documents/Gemsweeper Mac/build/Debug" -L/Developer/SDKs/MacOSX10.5.sdk/usr/local/lib -L/opt/local/lib "-F/Users/adriangrigore/Documents/Gemsweeper Mac/build/Debug" -F/Users/adriangrigore/Library/Frameworks -F/Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks -filelist "/Users/adriangrigore/Documents/Gemsweeper Mac/build/Gemsweeper Mac.build/Debug/Gemsweeper Mac.build/Objects-normal/i386/Gemsweeper Mac.LinkFileList" -mmacosx-version-min=10.4 /opt/local/lib/libboost_program_options-mt.a /opt/local/lib/libboost_filesystem-mt.a /opt/local/lib/libboost_serialization-mt.a /opt/local/lib/libboost_system-mt.a /opt/local/lib/libboost_thread-mt.a "/Users/adriangrigore/Documents/Gemsweeper Mac/3rd party/FreeImage/Dist/libfreeimage.a" "/Users/adriangrigore/Documents/Gemsweeper Mac/3rd party/cpuinfo-1.0/libcpuinfo.a" -L/usr/local/lib -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL -lwx_macd_richtext-2.8 -lwx_macd_aui-2.8 -lwx_macd_xrc-2.8 -lwx_macd_qa-2.8 -lwx_macd_html-2.8 -lwx_macd_adv-2.8 -lwx_macd_core-2.8 -lwx_base_carbond_xml-2.8 -lwx_base_carbond_net-2.8 -lwx_base_carbond-2.8 -framework SDL -framework Cocoa -o "/Users/adriangrigore/Documents/Gemsweeper Mac/build/Debug/Gemsweeper Mac.app/Contents/MacOS/Gemsweeper Mac"

Please note that I have already asked a similar question regarding the Xcode debugger here, but I am reposting since I just learned that this is in fact not Xcode's fault, but a problem with GCC / ld / GDB.

Edit: My project makes use of the following third-party libraries: SDL, Boost, wxWidgets. I am not sure if this matters for this problem, but I just wanted to mention it just in case it does.

I've tried compiling an Xcode SDL project template and did not experience the same problem, so it must be due to something special in my project.

Second Edit: As I just found out, I made a mistake while searching files with the string "This is an automatically generated". I just found several dozen files with the same string, all belonging to FreeImage, one of the third party libraries I am using. So, the problem seems to be related to FreeImage, but I am not still not sure how to proceed.

回答1:

I got those symptoms, when my gdb version didn't match my g++ version.

Try to get the newest gdb.

回答2:

Your cpp files certainly have debug symbols in them (the -gdwarf-2 option).

Do you use a separate dSYM file for the debug symbols? Or are they inside the object files. I would first try to use DWARF in dSYM files and see if that helps (or vice versa)

The third party libraries appear to be release builds though (unless you renamed them yourself of course) e.g. I know for sure boost uses the -d monniker in the library names to denote debug libraries (e.g. libboost_filesystem-mt-d.a).

Now, this shouldn't really pose a problem, it should just mean you can't step into the calls made to third party libraries. (at least not make any sense of it when you do ;) But since you have problems, it might be worth a try to link with debug versions of those libraries...

回答3:

Are you compiling with optimization on? I've found that O2 or higher messes with the symbols quite a bit, making gdb and core files pretty much useless.

Also, be sure you are compiling with the -g option.

回答4:

Can it be that you are using SDL? SDL redefines main so your main will be named SDL_main and that the SDL parts might be heavy optimized so down there you'll have problem getting good gdb output.

...just a thought

Read this

回答5:

For a test, you could check if addr2line gives you expected values. If so, this would indicate that there's nothing wrong with the ELF generated by your compile/link parameters and casts all suspicion on GDB. If not, then suspicion is still on both the tools and the ELF file.

回答6:

I've tried compiling an XCode SDL project template and did not experience the same problem, so it must be due to something special in my project.

Correct. Your project settings are the thing that is different.

You will need to disable the debug optimizations in the Xcode project settings for the debug build. Xcode unfortunately makes GDB jump to weird lines (out of order) when you would expect it to move sequentially.

Go to your project settings. Set the following

1) Instruction Scheduling   = None
2) Optimization Level       = None [-O0]
3) ZERO_LINK                = None

Your problems should go after after doing this. Here is the project settings screen that you need to change the settings on:

回答7:

From your flags the debug information should be in the object files.

Does your project settings build the executable in one location then move the final executable to another location when completed? If this is the case then gdb may not be finding the objectects files and thus not correctly retrieving the debug information from the object files.

Just a guess.

回答8:

I encountered this several years ago when transitioning from the Codewarrior compilers to Xcode. I believe the way to get around this is to put the flag "-fno-inline-functions" in Other C Flags (for Dev only).

This problem was more pronounced on the PowerPC architecture for us.

What about if you remove the "-fvisibility-inlines-hidden" and "-mfix-and-continue" flags?

I've never had the "fix and continue" feature work properly for me.

回答9:

WxWidgets do also define their own main if you use their IMPLEMENT_APP() macro

From here

As in all programs there must be a "main" function. Under wxWidgets main is implemented using this macro, which creates an application instance and starts the program.

IMPLEMENT_APP(MyApp)

回答10:

See my answer here

I have now downloaded and compiled the FreeImage sources and yes, the file b44ExpLogTable.cpp is compiled into libfreeimage.a. The problem looks like the script gensrclist.sh just collects all .cpp files without skipping the one with a main in. That script generates a file named Makefile.srcs but one is already supplied. (running it on my Leopard failed, some problem with sh - it worked if I changed sh to bash)

Before you have changed anything this gives an a.out

c++ libfreeimage.a

The file Makefile.srcs has already been created so you should be able to remove the file b44ExpLogTable.cpp from it. Then do

make -f Makefile.osx clean
make -f Makefile.osx

When this is done the above c++ libfreeimage.a should give the following error

Undefined symbols:
  "_main", referenced from:
      start in crt1.10.5.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

回答11:

I have a new thing you can try.

Just before your own main you can write

#ifdef main
#  error main is defined
#endif

int main(int argc, char *argv[]) {

this should give an error if you have some header that redefines main.

If you define an own you might get an warning where a previous definition was made

#define main foo

int main(int argc, char *argv[]) {

You can also try to undef just before your main

#undef main

int main(int argc, char *argv[]) {