Yes, gdb should look in all the dSYM's that are associated with the libraries loaded into the program you are debugging. Note you can use:
(gdb) info shared
to list all the libraries and their associated dSYMs. That's useful for checking that gdb really did find the dSYM's you think it should find.
The next step is to make sure the dSYM has the debug info you think it has. Find the dSYM that should contain the debug information for Unwind_RaiseException, and do:
dwarfdump<THAT LIBRARY> > /tmp/<THAT LIBRARY>.dwarf
Then look through this to see if it does indeed contain debug information for that symbol. You can even use the -f or --name options to get dwarfdump to limit the search.
The fact that you are getting "Could not find object file..." warnings means either that you didn't make dSYM's for some libraries you were loading, or that some .o files were deleted or moved before you made the dSYM for the library that included them.
Note that if you just don't move or delete the .o files that you used to build the libraries you are trying to debug, you don't need to make dSYM's. The linker puts a "debug map" into the executable that points back to the original .o files, and the Apple gdb can also dig the debug info out of them.
If you can find these symbols in the dSYM's associated with libraries loaded into your program, then please file a bug and we'll take a look.
Jim
On Nov 19, 2009, at 7:48 AM, Jack Howarth wrote:
I am trying to set a breakpoint under darwin9 for
FSF gcc's libgcc in Apple's gdb in order to debug an
unwinder issue with ecjx. The stock FSF gcc build
doesn't run dsymutil on libgcc so I resorted to
doing that manually in the build directories to
create the missing .dSYM. However I am finding that
Apple's gdb is unable to find Unwind_RaiseException
in libgcc when I try to set a breakpoint in ecjx that
is linked to it (even when setting LD_LIBRARY_PATH
and DYLD_LIBRARY_PATH to make sure the dylib next
to the dSYM is found). I do see warnings when gdb
loads the ecjx executable that...
warning: Could not find object file "/sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax/libltdlc.a/ltdl.o" - no debug information available for "../../../../gcc-4.5-20091116/libjava/libltdl/ltdl.c".
despite the presence of a dSYM for libgcj in the build
directory.
What is the expected behavior of Apple's gdb in this
case? If one has a program linked to shared libraries for
which not all of them have dSYM folders, one should be
able to set breakpoints for all of those libs for which
dSYM folders exist (correct)? Even if the calls in
question occur out of a shared lib which lacks the
dSYM, right? Or do you lose the ability to set break
points for subroutines if they are called from within
libs that are missing complete dSYMs?
Jack
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden