mikeash.com pyblog/friday-qa-2011-06-17-gdb-tips-and-tricks.html comments

Hugo Rumens - 2012-08-23 13:46:10

Thu, 23 Aug 2012 13:46:10 GMT

This article is a great resource.

One thing I would add is I've found that putting in a cast for the return type when doing a print-object is not always necessary, e.g. with a method returning a string, both of these work:



(gdb) po [someObject someMethodReturningNSString]

or

(gdb) po (NSString *) [someObject someMethodReturningNSString]

However, if trying to call a method that takes an argument:



- (NSString *)someMethod:(NSDictionary *)dict;

calling



(gdb) po (NSString *) [someObject someMethod:[NSDictionary dictionary]]

gives you the infamous (even though there is a return type cast)

Unable to call function "objc_msgSend" at 0x7fff84f100f4: no return type information available.

You have to cast the argument as well:



(gdb) po (NSString *) [someObject someMethod:(NSDictionary *) [NSDictionary dictionary]]

I've also found you can't pass nil - this won't work:



(gdb) po (NSString *) [someObject someMethod:(NSDictionary *) nil]

mikeash - 2011-07-15 01:13:12

Fri, 15 Jul 2011 01:13:12 GMT

Very cool, thanks!

Sagyuwara - 2011-07-14 02:27:56

Thu, 14 Jul 2011 02:27:56 GMT

I'm sorry for not responding sooner.
The link is http://www.cocoachina.com/bbs/read.php?tid-66525.html.
Thanks again.

mikeash - 2011-07-08 14:20:49

Fri, 08 Jul 2011 14:20:49 GMT

Please feel free to post translations, just provide attribution and a link to the original. If you do this, I'd love to see a link to the translation even if I can't understand it!

Sagyuwara - 2011-07-08 08:01:56

Fri, 08 Jul 2011 08:01:56 GMT

Very simple and clear article. Thanks a lot.

Is it allowed to translate and post it on other forums?

Ben - 2011-07-06 19:44:24

Wed, 06 Jul 2011 19:44:24 GMT

Awesome article, interesting to see the things it can do with Objective-C.

Don't forget about the step and finish commands (abbreviated s and f). They let you step into and out of the current function and are very useful for navigating shallow stacks when debugging in a localized area.

Mohamed - 2011-06-29 20:56:31

Wed, 29 Jun 2011 20:56:31 GMT

Very nice tutorial. Very nice.

SefTarbell - 2011-06-24 14:40:07

Fri, 24 Jun 2011 14:40:07 GMT

Excellent article, I have found myself struggling with anything in gdb outside the basic p & po. This gave me a bunch of new things to try!

ssp - 2011-06-21 06:09:13

Tue, 21 Jun 2011 06:09:13 GMT

Thanks for the examples, Mike.

mikeash - 2011-06-21 01:28:12

Tue, 21 Jun 2011 01:28:12 GMT

Xcode does allow you to access nearly everything gdb can do, but there are a couple of gotchas.

One is that if you ever need to run gdb as root, say, to debug a process that runs as root, Xcode gets really inconvenient.

The other is that Xcode's GUI wrapper is buggy. I've had bugs in my code which completely destroyed Xcode's debugger due to weird data propagating up to the UI layer, but which command-line gdb handled fine.

SSteve - 2011-06-20 22:00:15

Mon, 20 Jun 2011 22:00:15 GMT

Oh, sorry. I didn't notice the @ got removed. I thought that line of code was just a placeholder. I obviously need to try harder to read bugs. :-)

ssp - 2011-06-20 21:38:10

Mon, 20 Jun 2011 21:38:10 GMT

Very nice writeup, thanks a lot!

For curiosity's sake: care to give an example of something that doesn't work when using gdb from Xcode? I had the impression that – among the GUI-stuff – Xcode just offers a gdb console as well.

mikeash - 2011-06-20 21:31:22

Mon, 20 Jun 2011 21:31:22 GMT

If you mean the very first one under Getting Started, that's intended to be a working program. The bugs come later. It was tough to come up with realistic bugs, though....

SSteve - 2011-06-20 21:03:09

Mon, 20 Jun 2011 21:03:09 GMT

The first code example shouldn't have the @ before "Hello World!". You obviously need to try harder to write bugs. :-)

Pádraig Brady - 2011-06-20 11:56:01

Mon, 20 Jun 2011 11:56:01 GMT

My most common use of gdb is with: gdb -tui -args ....
That starts a curses interface which you can see in action here:
http://www.pixelbeat.org/programming/debugger/

mikeash - 2011-06-20 01:43:08

Mon, 20 Jun 2011 01:43:08 GMT

Running gdb separately is really only for when you can't, or at least don't want to, get Xcode involved at all. For example, debugging processes belonging to a different user, where you need to run the debugger as root, or getting gdb attached to some process for which there's no corresponding Xcode project, or unfortunate situations where you trigger bugs in Xcode which cause it to crash or otherwise fail at debugging. It's a nice skill to have because of that, but it doesn't really help except for specific situations.

Dad - 2011-06-19 20:06:47

Sun, 19 Jun 2011 20:06:47 GMT

GOLD! Great stuff! Thanks Mike.

Evgeniy Dzhurov - 2011-06-18 10:44:34

Sat, 18 Jun 2011 10:44:34 GMT

Thanks for the article, it's quite useful. And I have one question to add. As I'm used to running gdb from Xcode and occasionally throw in commands as I learn, are there any significant capabilities that I'm missing out by not running the debugger separately as per your advice. Perhaps something must-know for day to day Xcode development?

Vasi - 2011-06-17 21:33:16

Fri, 17 Jun 2011 21:33:16 GMT

If you want to provide arguments to the target at the command-line, you can use:

gdb --args /path/to/executable arg1 arg2 etc

Randy Becker - 2011-06-17 21:07:39

Fri, 17 Jun 2011 21:07:39 GMT

Great article, as always. I do wish you had mentioned x/s. I often use it to inspect selectors that will be passed to objc_msgSend().