As a lldb exercise, I am attempting to attach lldb to and set symbolic breakpoints in Apple's macOS TextEdit.app. I am able to set breakpoints in Foundation classes. But in private classes, it seems I always get Unable to resolve breakpoint to any actual locations. Why?
I understand that shipped executables are stripped, but I also understand that Objective-C symbol names cannot be stripped, and have read several old articles explaining how to "crack" apps, and it looks like it worked for them, albeit with gdb. And when I run otool -ov on the TextEdit executable, all of the private symbols and their addresses are shown.
Example
See how it works nicely for Foundation classes:
(lldb) breakpoint set -F "-[NSString initWithFormat:]"
Breakpoint 1: where = Foundation`-[NSString initWithFormat:], address = 0x00007fff2c0c29d0
(lldb) breakpoint set -r '\[NSString .*\]$'
Breakpoint 2: 139 locations.
But it fails when I try the same in the private Document class, or in one of its methods which I found by using Steve Nygard's class-dump:
(lldb) breakpoint set -F "-[Document validateMenuItem:]"
Breakpoint 3: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) breakpoint set -r '\[Document .*\]$'
Breakpoint 4: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
At present, lldb only uses the ObjC runtime data to provide type information for methods when they get called in the expression parser. It doesn't fold the methods found therein into the symbol table for breakpoint lookup.