Re: Breakpoint on arbitrary selector
Re: Breakpoint on arbitrary selector
- Subject: Re: Breakpoint on arbitrary selector
- From: Mike Bolton <email@hidden>
- Date: Wed, 26 Jan 2005 20:35:37 -0500
> Sometimes when I'm debugging (OK, or hacking) something, a selector
> that I know is implemented by one of the classes in the target project
> is just not recognized by the debugger. No tab-completion, etc. Even
> the class is not recognized. Yet looking up a class object by
> NSClassFromString and selector from NSSelectorFromString return
> reasonable looking values.
the reason you're not able to break on an Objective-C symbol is most
likely because the binary in question has been stripped of debugging
symbols.. To see what I mean, compile your own Cocoa app, then run nm
on it and notice that all the objective-c symbols are plainly visible.
If you then run the strip command on the binary, then re-run nm,
you'll see that all the objective-c symbol information has been
removed.
It's important to note that even when a binary has been stripped, the
objective-c symbol information is still available from the objective-c
segment. Unfortunately, gdb only relies on the symtab segment for
it's objective-c symbol parsing, so once this information has been
stripped, gdb can't set a breakpoint on an objective-c method.
You can, however, use otool to determine the method implementation
addresses to manually set a breakpoint on methods whose symbols have
been removed. For example, to find the address of the method
"addAppointment:", you can do something like this: "otool -ov
<binaryname> | grep -A addAppointment:". You'll then see something
like "method_imp 0x00008518". You can then set a breakpoint in gdb on
this address.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden