IOS debugging skills: How to Debug using LLDB, ioslldb

IOS debugging skills: How to Debug using LLDB, ioslldb
Preface

Debugging tracking is required during development. However, although many developers have done many projects, they do not necessarily know which Debugging commands in the development can help our developers locate problems faster and better.

This article mainly explains how to use LLDB for debugging during development. First, I will talk about some basic knowledge, mainly to help new users learn how to debug. For some advanced operations, it does not matter, but if you can grasp it, it will be easier and faster to find problems.

A preliminary understanding of LLDB

LLDB is a built-in debugging tool provided by XCode for our developers. I still don't know what debugging is. I don't know how to describe Baidu. Let's take a look at it. You can probably understand what debugging is!

We added a breakpoint and stopped it when we ran it to the breakpoint. Then we can see lldb here? We can operate through the commands provided by lldb.

Basic Debugging operations

Let's talk about the first five buttons in the eight buttons:

• Click the first button to collapse the column and you will not be able to see it.

• The second button: If it is blue, the breakpoint is valid. If you click it to become gray, all breakpoints do not work.

• The third button: "continue" means that the program will resume running from the breakpoint. After we click this button, the application will resume normal operation.

• The fourth button indicates the execution in a single step. Once this button is clicked, the program executes one step down from where the breakpoint starts.

• The fifth button means to enter the execution. Simply put, if our current breakpoint is on a function call, the breakpoint will continue to enter the function for internal debugging.

• The sixth button means that if we are in a function, it will jump out of the current function and return to the function call.

Common p, po, and call commands

First look:

The following is printed when you enter the help command. You can see what are the differences between the four:

123456789101112

p         -- ('expression --')  Evaluate an expression (ObjC++ or Swift) in               the current program context, using user defined variables and               variables currently in scope.po        -- ('expression -O  -- ')  Evaluate an expression (ObjC++ or Swift)               in the current program context, using user defined variables and               variables currently in scope.print     -- ('expression --')  Evaluate an expression (ObjC++ or Swift) in               the current program context, using user defined variables and               variables currently in scope.call      -- ('expression --')  Evaluate an expression (ObjC++ or Swift) in               the current program context, using user defined variables and               variables currently in scope.

From the official description, p, print, and call are the same, but po is not the same. The input is the same but the output is different. Po outputs the content of a specific object.

If you want to print data in a specific format:

12345678

(lldb) p/s blogName(__NSCFConstantString *) $9 = @"'S technical blog"(lldb) p/x blogName(__NSCFConstantString *) $10 = 0x000000010921c0a8 @"'S technical blog"(lldb) p/t blogName(__NSCFConstantString *) $11 = 0b0000000000000000000000000000000100001001001000011100000010101000 @"'S technical blog"(lldb) p/a blogName(__NSCFConstantString *) $12 = 0x000000010921c0a8 @ @"'S technical blog"

For more information about this rule, see print output formatting.

Lldb declares Variables

We can use the e command to define variables and then use them in debugging. See the following example:

12345678910

(lldb) e NSString *$str = @"http://www.henishuo.com"(lldb) po $strhttp://www.henishuo.com (lldb) e int $count = 10(lldb) p $count(int) $count = 10(lldb) e NSArray *itemArray = @[@"Test", @"Demo", @"huangyibiao"](lldb) po $count10

Have we declared variables starting with e? We also need to add the $ symbol in the declaration and use, just like PHP!

During debugging, when you want to temporarily calculate a value for comparison, You can implement it in this way. You no longer need to add Declaration implementation to the source code and then add a print sentence, is it much more convenient?

Call the variable API

When we define the blogName variable at the breakpoint, we can call

12345

(lldb) po [blogName uppercaseString]GE's technical blog (lldb) po [blogName substringFromIndex:2]Technical blog

Type of strongly converted Return Value

When the type of the returned value of an API call is not specified, sometimes the printed content cannot be understood. For example, the following result should be a "mark, however, different types of printing results are different:

1234567891011121314

(lldb) po [blogName characterAtIndex:0]26631 (lldb) po (unsigned int)[blogName characterAtIndex:0]26631 (lldb) po (char)[blogName characterAtIndex:0]'a' (lldb) po (NSString *)[blogName characterAtIndex:0]0x0000000000006807 (lldb) po (unichar)[blogName characterAtIndex:0]U+6807 u'Tag'

Add breakpoint

If we don't add all the breakpoints at the beginning, but want to add a breakpoint to other places after the Debugging starts, we can easily add the breakpoint through the command:

12	(lldb) b ? 33Breakpoint 9: where = OCLLDBDebugDemo`-[ViewController onButtonClicked:] + 53 at ViewController.m:33, address = 0x000000010921a6d5

This is to add a breakpoint to row 33 of the current class file. A prompt is displayed after the breakpoint is successfully added. The prompt here is that the breakpoint is successfully added to row 33. Of course, there are several ways to add breakpoints, such:

12	(lldb) b ?-[ViewController onButtonClicked:]Breakpoint 4: where = OCLLDBDebugDemo`-[ViewController onButtonClicked:] + 53 at ViewController.m:33, address = 0x000000010921a6d5

Actually, a breakpoint is added in row 33. However, if we want to add a breakpoint dynamically, we can use the B command to add a line number. This is the easiest way.

Set breakpoint trigger conditions

See how I set the trigger conditions:

We have set a condition in the NSLog line. The breakpoint will be started only when the condition is full, but it is not set to break the breakpoint here, when the conditions are met, a sound is sent and a prompt is printed.

This kind of application scenario is mainly used to traverse data in a loop. You can only use this method if you want to trace the data through a breakpoint. Unless you add NSLog printing, You need to manually add the code, it is too slow to add some print statements when debugging. If you know how to set the breakpoint conditions, you can meet our needs and set the conditions directly.

Common print view hierarchies

When we want to know the structure of a view, we can call the recursiveDescription method to print it out, so the structure is clear:

12	(lldb) po [self.view recursiveDescription] ? | ? | ? ?| ? | ? ?| ? ?|(layer) ? | ? |

Temporary UI refresh

In this demo, the background color of the Start button is blueColor. Now we need to change the background color to red during debugging and refresh the interface. Run the following command line. The background color of the button on the App interface is:

(lldb) e ((UIButton *)sender).backgroundColor = [UIColor redColor](UICachedDeviceRGBColor *) $41 = 0x00007fdd10715b00(lldb) e (void)[CATransaction flush]

After the preceding command is executed, the background color of the buttons on the App interface is:

This method is very useful. When debugging the UI, the background color is not easily distinguished because of similar colors, but we can modify the background color in this way during debugging, you don't have to write the corresponding code to the source code to re-run it to see the effect.

After running the preceding command under debugging, the background color of the button becomes red!

Last

The main purpose of writing this article is that the younger apprentice does not quite understand debugging. Write this article to help the younger apprentice and help everyone better learn to debug code during development. In fact, there are still many Debugging commands, but they are not commonly used. I will not list them here. If you want to learn more, enter help to view them!

Q: one-click call to programmer Q & A artifacts, one-to-one service, developer programming required official website: www.wenaaa.com

QQ Group 290551701 has gathered many Internet elites, Technical Directors, architects, and project managers! Open-source technology research, welcome to the industry, Daniel and beginners interested in IT industry personnel!