WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Discover breakpoint improvements

Discover breakpoint improvements

Developer ToolsDebugging
Watch original video

Highlight

Xcode 13 adds column breakpoints, unresolved breakpoint prompts, and runtime problem breakpoints to breakpoints, allowing developers to pause the program at specific expressions, symbol parsing failure points, and runtime problems.

Core Content

When debugging, what the developer really wants is to stop the program before an error occurs. After stopping, you can check the process status and verify the logic step by step.

In the past, line breakpoints were most commonly used. It’s suitable for stopping at a certain line, but there may be multiple expressions in one line of code. The compiler generates multiple stop locations for these expressions. you want to enterconvertedToVolume, the debugger may first enteradjustedDensity. Then you have to step out, then step in. After repeating it several times, the debugging rhythm is broken.

Xcode 13 solves this problem of granularity. It adds column breakpoint (Column Breakpoint). Developers can place breakpoints on an expression on the same line. When the program is paused, Xcode will also use Column PC to draw a green underline under the expression to tell you which expression will be executed next.

Symbolic breakpoints have similar pain points. You enter a function name and LLDB will match it in all libraries loaded by the process. When the function name is too common, there may be hundreds of hits. When the function name is misspelled, the breakpoint keeps missing and you can only guess why.

Xcode 13 adds dotted icons and tips for unresolved breakpoints. It will point out common causes: whether the symbol name is misspelled, whether the symbol exists, whether the library has been loaded, whether the source code line participated in the compilation, and whether the module generated debugging information.

Runtime issues are the third type of scenario. For example, modify the UI state in the background thread. By default, Xcode will log the call stack to the Issue navigator but will not pause the program. After the problem has occurred, looking at the current process status is usually of limited help. Runtime problem breakpoints can stop the program when a problem occurs.

Detailed Content

Column breakpoint: specific expression that stops in a row

(02:27) line breakpoints pause on source code lines. When encountering multiple expressions in a line, LLDB will choose a stopping position based on the line table generated by the compiler. Xcode 13’s column breakpoints advance the stopping point to the expression level.

The key operations are as follows.

Command-click expression
Select "Set Column Breakpoint"
Continue execution
Check the green underscore from Column PC
Step into the highlighted expression

Key points:

  • Command-click expression: Opens the Actions popover on the target expression. -Set Column Breakpoint: Bind the breakpoint to the expression of this column. -Continue execution: Continue running until the column breakpoint is hit. -Column PC: A green underline marks the expression that the debugger will execute next. -Step into: Confirm that the underline is under the target expression before executing single-step entry.

(04:15) This capability is more practical for Swift closures and Objective-C blocks. There may be multiple closures in a Swift line. Previously, you could only break points on the entire line and then step in and step out repeatedly. Now you can directly add the last$0Set a column breakpoint on.

The key operations are as follows.

Command-click the last $0
Select "Set Column Breakpoint"
Inspect $0 when the debugger pauses

Key points:

  • the last $0: The target is the anonymous parameter of the last closure on the same line. -Set Column Breakpoint: Let LLDB pause at the line table entry corresponding to the closure. -Inspect $0: The pause position has fallen within the target closure, and the anonymous parameters can be viewed directly.

Symbolic breakpoint: pause by function name and limit module scope

(05:27) Symbolic Breakpoint pauses by function name. It is suitable for two situations: there is no source code file, or many subclasses implement the same function, and you do not want to set breakpoints on each file.

The path to create symbolic breakpoints in Xcode is as follows.

Breakpoint Navigator
Add button
Symbolic Breakpoint
Symbol: toggle
Module: Fruta

Key points:

  • Breakpoint Navigator: Breakpoint management entry. -Add button: Open the list of breakpoint types that can be created. -Symbolic Breakpoint: Select to pause by symbol name. -Symbol: toggle: Enter the function name to be matched. -Module: Fruta: Limit the matching scope to the application main binary to prevent symbols with the same name in the system library from hitting together.

(06:34) When the function name is a common word, the module must be restricted. LLDB will match symbols in all libraries loaded by the process. limited toFrutaLater, the hit locations in the demo were narrowed down from a potentially large number of results to just three.

Unresolved breakpoints: finding typos with icons and LLDB

(07:59) Xcode 13 will display breakpoints that are not resolved anywhere by LLDB as dotted icons. Hover over the icon and Xcode will give you a common explanation.

Common reasons are as follows.

Symbol name must be spelled correctly
Symbol must exist in its library
Library for the breakpoint must be loaded
Source line must be compiled
Module must have debug info

Key points:

  • Symbol name: The function name of the symbolic breakpoint needs to be spelled correctly. -Symbol must exist: The symbol needs to exist in the specified library. -Library ... loaded: The library may be loaded after user operation, and LLDB will automatically parse it after loading. -Source line ... compiled: The line where the source code breakpoint is located needs to participate in compilation. -debug info: The module needs to generate debugging information, otherwise the source code breakpoints cannot be parsed.

(09:15) In the demonstration, the developerconvertedToMassDoneconvertToMass. Search directly in the source codeconvertYou will get multiple results. A faster method is to use LLDB in the Xcode console to search for the symbol name in the process.

image lookup -rn convert Fruta

Key points:

  • image: Also stands for module in LLDB. -lookup: Find symbol information in the module. --r: Use regular expression matching. --n: Find by name. -convert: The symbol name fragment to search for. -Fruta: Limit the search to application modules.

This command returns only 4 matches in the demo. The result shows that the correct function name isconvertedToMass. After copying it back to the breakpoint editor, LLDB successfully resolved to 1 location.

Source code breakpoint is not resolved: check compilation conditions and debugging information

(10:22) Unresolved breakpoints will also appear on source code breakpoints. The breakpoint in the demo is placed on line 23, but this line is in the compiler conditionelsebranch, it is not compiled by the current build.

The troubleshooting path is as follows.

Check whether the source line is compiled
Check build settings for debug info

Key points:

  • source line is compiled: The line where the breakpoint is located must enter the current build product. -build settings: If the module does not generate debug information, you need to check the build settings. -debug info: The debugger relies on debugging information to map source code locations to compiled addresses.

Runtime problem breakpoint: pause when the problem occurs

(10:49) Runtime issues (Runtime Issues) are problems that occur during the running phase. The example given in the talk is modifying UI state from a background thread. The default behavior is to record the backtrace (call stack) and display it in the Issue navigator.

If you want to examine the status of the process when a problem occurs, you can create a runtime problem breakpoint.

Add Runtime Issue Breakpoint
Choose a specific type in the type popup
Open Scheme Editor
Diagnostics tab
Enable Main Thread Checker

Key points:

  • Runtime Issue Breakpoint: Causes the debugger to pause when a runtime problem occurs. -type popup: Select a specific question type. -Scheme Editor: Some runtime problem breakpoints require the corresponding diagnostic capabilities to be enabled first. -Diagnostics tab: Diagnostic switch location. -Main Thread Checker: Diagnostic functionality used in the demo to capture runtime issues related to the main thread.

Core Takeaways

  • What: Create an “expression-level debugging manifest” for complex Swift call chains. Why it’s worth doing: Column breakpoints can stop at specific expressions in the same line, which is suitable for debugging Swift code with multiple closures and multiple function calls. How ​​to start: Find the long lines containing multiple closures in the project, at the key$0Or Command-click on the target call, set a column breakpoint, and then use Column PC to confirm the pause position.

  • What: Establish a symbolic breakpoint for an implementation of the same name as a protocol or base class. Why it’s worth doing: Symbolic breakpoints can cover functions of the same name in multiple classes at once, eliminating the need to break points one by one. How ​​to start: Create a new Symbolic Breakpoint in Breakpoint Navigator, fill in the function name for Symbol, and fill in the application binary name for Module.

  • What to do: Write the “breakpoint not hit” troubleshooting process into the team debugging document. Why it’s worth doing: Xcode 13 shows unresolved breakpoints for LLDBimage lookup -rnCan quickly verify symbol names. How ​​to start: Run in Xcode consoleimage lookup -rn <name> <module>, confirm the real symbol name, and then correct the Symbol in the breakpoint editor.

  • What: Create dedicated runtime issue breakpoints for UI thread issues. Why it’s worth it: Issue navigator can only show issues that have already occurred; runtime issue breakpoints allow you to inspect variables and call stacks on the spot. How ​​to start: Open Main Thread Checker in the Diagnostics tab of Scheme Editor, and then add Runtime Issue Breakpoint.

  • What: Keep debug check steps next to conditionally compiled code. Why it’s worth doing: The source code breakpoint may not be resolved because the current build does not compile the line. How ​​to start: When encountering a dotted breakpoint, first check whether the line falls within the current compiler condition, and then check whether the module generates debug info.

Comments

GitHub Issues · utterances