top products

So the first thing i noticed when debugging Applications with Xcode is that there’s no GUI for inspecting objects. i mean, an array has some certain objects and printing all to the console is not very user-friendly, so let’s improve things a bit.

This problem really got me thinking why there’s no better way of displaying the data and i broke things down to the problem, that objects are located inside the target application. Gdb doesn’t have these objects for itself and neither does Xcode. I tried around a bit and came up with what i consider a good start to begin improving the debugging process in OS X.

First i had a look at how gdb is doing it’s po command. It’s basically calling NSPrintForDebugger(someObject) and then it’s copying the result (a C string) byte by byte into gdb and displays it.

That lead to the idea of sending something bigger towards gdb. The problem is that gdb has to understand what it gets and the app has to understand what gdb wants. So this is asking for extensions on both sides, which made me create a plugin for gdb and an input manager to patch the cocoa framework.

First i’ll describe the input manager a bit better: My idea is to send data to gdb, but it’s not so easy to get data from every object. I created a new class to do the work for me. It takes any object and tries to encode that object (maybe i should implement the NSCoding protocol in NSObject as well, but i didn’t do that yet). Then i made a simple structure that stores two pieces of information, the size of the data and a pointer to the data. This structure is what gdb receives.

The plugin for gdb defines a command called bs_get_data_from and the argument is some object. Once the application provides the data of that object, gdb copys these bytes into a local buffer and recreates the structure. Then the structure is decoded. The result is that the object that was formerly on the target side is now on the debugger side and can be abused for a variety of fancy stuff.

I’m a Smalltalk guy and i really like the way VisualWorks allows me to examine objects. There are inspectors that show all the interesting information. If there is an Array with three Strings, Xcode could open a window listing all three strings. If the array contains data, inspecting each object of the array could open a hex-editor for that data. Anyway, this is future talk and i didn’t implement much of the Xcode integration yet, only the gdb and the input manager are “working” (it’s just a prove of concept project atm).

So what does it look like currently in gdb? In the log below i have an array with three strings. gdb is querying for the array and the target application is logging what is does. Then the data is passed to gdb and gbd logs what it does.

This part is what the target app logs.

(gdb) bs_get_data_from array
2007-02-15 02:46:35.889 DebugTest[6085] targetObject = (string1, string2, string3) and it is: no class
2007-02-15 02:46:35.890 DebugTest[6085] data is present:
 <62706c69 73743030 d4010203 04050607 0a592461 72636869 76657258 24766572 73696f6e 5424746f 7058246f 626a6563 74735f10 0f4e534b 65796564 41726368 69766572 12000186 a0d10809 5b646562 75674f62 6a656374 8001a80b 0c151c1d 1e1f2555 246e756c 6cd40d0e 0f101111 13145f10 0f425349 73507379 646f4f62 6a656374 5f100f42 53497343 6c617373 4f626a65 63745224 30562463 6c617373 08088002 8007d216 10171b5a 4e532e6f 626a6563 7473a318 191a8003 80048005 80065773 7472696e 67315773 7472696e 67325773 7472696e 6733d220 21222358 24636c61 73736573 5a24636c 6173736e 616d65a2 2324574e 53417272 6179584e 534f626a 656374d2 20212627 a227245d 42534465 6275674f 626a6563 74000800 11001b00 24002900 32004400 49004c00 58005a00 63006900 72008400 96009900 a000a100 a200a400 a600ab00 b600ba00 bc00be00 c000c200 ca00d200 da00df00 e800f300 f600fe01 07010c01 0f000000 00000002 01000000 00000000 28000000 00000000 00000000 00000001 1d>
2007-02-15 02:46:35.890 DebugTest[6085] data is at: 0x374350 with 397 bytes

The rest is from the gdb plugin

structLength = 397
data is at = 0x374350, buffer is at: 0x224af20
2007-02-15 02:46:35.893 gdb-i386-apple-darwin[6078] ds->size = 397, ds->data = 0x224af20
2007-02-15 02:46:35.893 gdb-i386-apple-darwin[6078] object is :
,
 data is: 
<62706c69 73743030 d4010203 04050607 0a592461 72636869 76657258 24766572 73696f6e 5424746f 7058246f 626a6563 74735f10 0f4e534b 65796564 41726368 69766572 12000186 a0d10809 5b646562 75674f62 6a656374 8001a80b 0c151c1d 1e1f2555 246e756c 6cd40d0e 0f101111 13145f10 0f425349 73507379 646f4f62 6a656374 5f100f42 53497343 6c617373 4f626a65 63745224 30562463 6c617373 08088002 8007d216 10171b5a 4e532e6f 626a6563 7473a318 191a8003 80048005 80065773 7472696e 67315773 7472696e 67325773 7472696e 6733d220 21222358 24636c61 73736573 5a24636c 6173736e 616d65a2 2324574e 53417272 6179584e 534f626a 656374d2 20212627 a227245d 42534465 6275674f 626a6563 74000800 11001b00 24002900 32004400 49004c00 58005a00 63006900 72008400 96009900 a000a100 a200a400 a600ab00 b600ba00 bc00be00 c000c200 ca00d200 da00df00 e800f300 f600fe01 07010c01 0f000000 00000002 01000000 00000000 28000000 00000000 00000000 00000001 1d>
2007-02-15 02:46:35.893 gdb-i386-apple-darwin[6078] targetobject is :
<(string1, string2, string3)>

I really hope this little project inspired someone out there! I’m really short in time and also don’t have a deep knowledge of all the stuff involved. I just wanted to show that these things are possible. If the Xcode integration is done correctly, then any object can be inspected there. Developers should also be able to write their own plugins for it to display their own objects in a more specific way.

If anyone wants to have a look at the stuff i made, it’s available here. Keep in mind that i pretty much hacked that code together without thinking to much about design or that stuff…. i just wanted to have it working 😉
For some reason, the gdb plugin is not linking for ppc, so maybe someone can post a solution for that in the comments.

Karsten

Posted on Thursday, February 15th, 2007 at 3:05 under New ideas.
RSS-Feed for Comments | Print | No Respondes allowed | No Trackback link