Is there a way to import the output from class-dump
into GDB?
Example code:
$ cat > test.m #include <stdio.h> #import <Foundation/Foundation.h> @interface TestClass : NSObject + (int)randomNum; @end @implementation TestClass + (int)randomNum { return 4; // chosen by fair dice roll. // guaranteed to be random. } @end int main(void) { printf("num: %d\n", [TestClass randomNum]); return 0; } ^D
$ gcc test.m -lobjc -o test $ ./test num: 4 $ gdb test ... (gdb) b +[TestClass randomNum] Breakpoint 1 at 0x100000e5c (gdb) ^D $ strip test $ gdb test ... (gdb) b +[TestClass randomNum] Function "+[TestClass randomNum]" not defined. (gdb) ^D
$ class-dump -A test ... @interface TestClass : NSObject { } + (int)randomNum; // IMP=0x0000000100000e50 @end
I know I can now use b *0x0000000100000e50
in gdb
, but is there a way of modifying GDB's symbol table to make it accept b +[TestClass randomNum]
?
Edit: It would be preferably if it would work with GDB v6 and not only GDB v7, as GDB v6 is the latest version with Apple's patches.
It’s possible to load a symbol file in gdb with the add-symbol-file
command. The hardest part is to produce this symbol file.
With the help of libMachObjC (which is part of class-dump), it’s very easy to dump all addresses and their corresponding Objective-C methods. I have written a small tool, objc-symbols which does exactly this.
Let’s use Calendar.app as an example. If you try to list the symbols with the nm
tool, you will notice that the Calendar app has been stripped:
$ nm -U /Applications/Calendar.app/Contents/MacOS/Calendar 0000000100000000 T __mh_execute_header 0000000005614542 - 00 0000 OPT radr://5614542
But with objc-symbols
you can easily retrieve the addresses of all the missing Objective-C methods:
$ objc-symbols /Applications/Calendar.app 00000001000c774c +[CALCanvasAttributedText textWithPosition:size:text:] 00000001000c8936 -[CALCanvasAttributedText createTextureIfNeeded] 00000001000c8886 -[CALCanvasAttributedText bounds] 00000001000c883b -[CALCanvasAttributedText updateBezierRepresentation] ... 00000001000309eb -[CALApplication applicationDidFinishLaunching:] ...
Then, with SymTabCreator you can create a symbol file, which is just actually an empty dylib with all the symbols.
Using objc-symbols
and SymTabCreator
together is straightforward:
$ objc-symbols /Applications/Calendar.app | SymTabCreator -o Calendar.stabs
You can check that Calendar.stabs
contains all the symbols:
$ nm Calendar.stabs 000000010014a58b T +[APLCALSource printingCachedTextSize] 000000010013e7c5 T +[APLColorSource alternateGenerator] 000000010013e780 T +[APLColorSource defaultColorSource] 000000010013e7bd T +[APLColorSource defaultGenerator] 000000010011eb12 T +[APLConstraint constraintOfClass:withProperties:] ... 00000001000309eb T -[CALApplication applicationDidFinishLaunching:] ...
Now let’s see what happens in gdb:
$ gdb --silent /Applications/Calendar.app Reading symbols for shared libraries ................................. done
Without the symbol file:
(gdb) b -[CALApplication applicationDidFinishLaunching:] Function "-[CALApplication applicationDidFinishLaunching:]" not defined. Make breakpoint pending on future shared library load? (y or [n]) n
And after loading the symbol file:
(gdb) add-symbol-file Calendar.stabs add symbol table from file "Calendar.stabs"? (y or n) y Reading symbols from /Users/0xced/Calendar.stabs...done. (gdb) b -[CALApplication applicationDidFinishLaunching:] Breakpoint 1 at 0x1000309f2
You will notice that the breakpoint address does not exactly match the symbol address (0x1000309f2 vs 0x1000309eb, 7 bytes of difference), this is because gdb automatically recognizes the function prologue and sets the breakpoint just after.
You can use this GDB script to automate this, given that the stripped executable is the current target.
Add the script from below to your .gdbinit
, target the stripped executable and run the command objc_symbols
in gdb:
$ gdb test ... (gdb) b +[TestClass randomNum] Function "+[TestClass randomNum]" not defined. (gdb) objc_symbols (gdb) b +[TestClass randomNum] Breakpoint 1 at 0x100000ee1 (gdb) ^D
define objc_symbols shell rm -f /tmp/gdb-objc_symbols set logging redirect on set logging file /tmp/gdb-objc_symbols set logging on info target set logging off shell target="$(head -1 /tmp/gdb-objc_symbols | head -1 | awk -F '"' '{ print $2 }')"; objc-symbols "$target" | SymTabCreator -o /tmp/gdb-symtab set logging on add-symbol-file /tmp/gdb-symtab set logging off end
There is no direct way to do this (that I know of), but it seems like a great idea.
And now there is a way to do it... nice answer, 0xced!
The DWARF file format is well documented, IIRC, and, as the lldb source is available, you have a working example of a parser.
Since the source to class-dump is also available, it shouldn't be too hard to modify it to spew DWARF output that could then be loaded into the debugger.
Obviously, you wouldn't be able to dump symbols with full fidelity, but this would probably be quite useful.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With