Jack Howarth wrote: > On Fri, Oct 03, 2008 at 08:29:40PM -0500, Peter O'Gorman wrote: >> Jack Howarth wrote: >>> On Tue, Aug 05, 2008 at 11:31:13AM -0500, Peter O'Gorman wrote: >>>> Jack Howarth wrote: >>>>> Does anyone know why gdb appears to be unable to find the debug >>>>> information >>>>> for libstdc++ in gcc 4.3 and gcc trunk on darwin9? This has been reported >>>>> before >>>>> as... >>>>> >>>>> https://trac.macports.org/ticket/16102 >>>>> >>>>> Under current gcc trunk, using Apple's current Xcode 3.1's gdb reports the >>>>> errors of the form... >>>>> >>>>> warning: Could not find object file >>>>> "/sw/src/fink.build/gcc44-4.3.999-20080803/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o" >>>>> - no debug information available for >>>>> "../../../../gcc-4.4-20080803/libstdc++-v3/libmath/signbit.c". >>>>> >>>>> when I try to run a binary linked to libstdc++ in gdb. My gcc build >>>>> directory doesn't >>>>> have a libstdc++.lax directory left in it. Is this a flaw in the .la >>>>> files for gcc? >>>>> Thanks in advance for any advice. I am trying to puzzle out if this is a >>>>> gcc bug or >>>>> a gdb bug so that I can file a radar report against gdb if it is the >>>>> later. >>>>> Jack >>>>> >>>> The debug information is stored in the object files. Libtool uses a >>>> convenience library, and, because darwin's linked does not have the >>>> equivalent of --whole-archive --no-whole-archive to ensure that all >>>> members of specific archives are loaded, it unpacks the archive and adds >>>> all the objects. Having created the output, it then deletes these >>>> objects, leaving the debugger with no object files. >>>> >>>> This is "fixed" in recent GNU libtool by calling dsymutil on the newly >>>> created shared library. I have not checked if gcc's version of libtool >>>> has this change. I'll check when I have time and submit a patch if that >>>> is not the case. >> >>> Peter, >>> I am still seeing this problem with the current gcc trunk after the >>> libtool update. Are we still messing some additional changes for darwin >>> to eliminate these problems with Apple's gdb not properly finding the >>> object files for libstdc++? >>> Jack >> Hi Jack, >> >> How are you starting GDB? Is your build tree still around with all the >> object files in it? >> >> Peter >> -- >> Peter O'Gorman >> http://pogma.com > > Peter, > If I compile a short c++ program like... > > #include <iostream> > using namespace std; > main() > { > cout << "Hello World!" << endl; cout << "Welcome to C++ Programming" << > endl; } > > with the g++ compiler from gcc trunk and execute... > > gdb a.out > > ...using the Xcode 3.1.1 gdb under MacOS X 10.5.5 on Macintel, I get... > > warning: Could not find object file > "/sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o" > - no debug information available for > "../../../../gcc-4.4-20081001/libstdc++-v3/libmath/signbit.c". > > ..etc. The build directory from my fink packaging is still remaining but I > get... > > ls -l > /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o > ls: > /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/libstdc++.lax/libmath.a/signbit.o: > No such file or directory > > The > /sw/src/fink.build/gcc44-4.3.999-20081001/darwin_objdir/i686-apple-darwin9/libstdc++-v3/src/.libs/ > directory exists but it > doesn't contain a libstdc++.lax subdirectory. > Jack
Jack, Some libraries are created from GNU libtool convenience archives, on darwin. Those used to be included in the archive with the -all_load flag to the static linker, but this was not ideal, as the -all_load flag adds every member of every archive to the output. So this was changed to the current system where archives that need all members to be added to the output are extracted (fat archives are dealt with with lipo), and all the individual objects are then added to the output. Because these convenience archives can, for some projects, involve thousands of object files, once the output is created, GNU libtool deletes the object files that it created in that temporary directory. Because, on Mac OS X, DWARF-2 debugging information is stored in the object file, I received reports (from Apple engineers) that it was difficult to debug libraries in this case (the object files had been removed, so GDB was unable to find the debug information). I added the dsymutil step to library linking to allow developers to debug their shared libraries in the build tree. This works as long as the library that gdb finds is the one in the build tree that has the .dSYM directory sitting next to it. If a library containing debug information, but no corresponding object files or .dSYM directory is found by GDB then it will complain about it. If you create a library with DWARF-2 debugging and have finished debugging it, you should run strip -S on it to remove the debug information. If you want to debug libstdc++ you should do so in the build directory, ensuring that DYLD_LIBRARY_PATH is set such that the libstdc++ that is loaded has a libstdc++.dylib.dSYM sitting right next to it. I suppose, since I added the dsymutil step, I am now going to have to add a 'strip -S' step to remove the debugging information from every library that is built with GNU libtool, this will then stop GDB from whining when it finds an installed library with debugging information and no corresponding object files or .dSYM directory, but will continue to allow developers to debug libraries in the build tree. I would prefer that GNU libtool not have to do this, please file a radar asking for the equivalent of GNU ld's --whole-archive --no-whole-archive, if that is available, GNU libtool can stop running dsymutil or strip and leave those decisions up to the developer (where they should be). Peter -- Peter O'Gorman http://pogma.com
