Re: setting breakpoints in gdb
Re: setting breakpoints in gdb
- Subject: Re: setting breakpoints in gdb
- From: Jim Ingham <email@hidden>
- Date: Thu, 19 Nov 2009 13:08:23 -0800
Radar 3738966 is fixed in SnowLeopard.
Jim
On Nov 19, 2009, at 1:00 PM, Jack Howarth wrote:
> Jim,
> I believe this mailing list message explains the situation with the GNU libtool convenience archives
> on darwin...
>
> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
>
> I had opened radar 6270369 (which is a duplicate of 3738966) requesting that the darwin linker
> support the equivalent of linux ld's --whole-archive/--no-whole-archive option. Can you tell
> me what the status of the original radar report is? According to Peter O'Gorman that would be
> the best long term solution to the use of libtool convenience archives.
> Jack
>
>
> On Thu, Nov 19, 2009 at 11:16:01AM -0800, Jim Ingham wrote:
>> 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
_______________________________________________
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