[译] LLDB 基础

原文链接：https://swifting.io/blog/2016/02/19/6-basic-lldb-tips/
原作者：Michał Wojtysiak

长话短说

在开发了几年的iOS应用后，我对LLDB调试器的使用已经趋于最小：

(lldb) po data.pressure
98.65814208984375
 
(lldb) po samples.count
28
 
(lldb) po (x + y)*z
96

以上几乎就是我使用的全部了。这并不值得骄傲。设置一个断点，然后使用po命令。我知道po是'print object（输出对象）'的意思，并且能用它来计算表达式。我需要更先进的工具来帮我应对不得不处理的复杂难题。

让我们开始吧！

探究LLDB工作区

你总能够在调试的时候输入一个help命令：

(lldb) help
Debugger commands:
 
  apropos           -- Find a list of debugger commands related to a particular
                       word/subject.
 
...

你可能已经注意到就连apropos命令也是分外有趣的。让我们使用LLDB的'聪明才智'来为我们推荐设置断点的命令：

(lldb) apropos breakpoints
The following built-in commands may relate to 'breakpoints':
  breakpoint                -- A set of commands for operating on breakpoints.
                               Also see _regexp-break.
  breakpoint clear          -- Clears a breakpoint or set of breakpoints in the
                               executable.
  breakpoint command add    -- Add a set of commands to a breakpoint, to be
                               executed whenever the breakpoint is hit.  If no
                               breakpoint is specified, adds the commands to
                               the last created breakpoint.
 
 
...

LLDB还不赖嘛，还不赖。

LLDB必须要配合Xcode才能使用吗？

当然。。。不是咯！我们并不需要依赖Xcode的调试区域（Debug Area）。我们能够很轻易地从终端启动LLDB。在此之前我们需要先搭建一个app去模拟相应的环境。在终端切换到你的项目路径下输入：

michal$ xcodebuild -sdk iphonesimulator9.2

在路径：project_dir/build/Release-iphonesimulator/appname.app 下你就有了一个为调试而生的 *.app 文件。

现在，在不切换路径的前提下你就能够从终端启动LLDB了：

michal$ xcrun lldb
(lldb)

接着你需要像这样创建一个测试目标：

(lldb) target create ./build/Release-iphonesimulator/appname.app  
Current executable set to './build/Release-iphonesimulator/appname.app' (x86_64).

最后，启动一个进程来开始我们的任务：

(lldb) process launch

这样我们就和在Xcode中运行调试模式一样了。

标准的Ctrl+C命令无法让你退出LLDB，请使用quit命令：

(lldb) quit
michal$

为什么我需要在命令行使用LLDB？

如果你浏览了(lldb) apropos breakpoint给出的结果，你肯定意识到了很多可能的原因。想要获取更多针对断点的帮助请输入：

(lldb) help breakpoint

虽然Xcode有了一些用UI实现的调试特性：

• Breakpoint Navigator (⌘ + 7)

• Debug Navigator (⌘ + 6)

• Debug Area (⌘ + Shift + Y)

• Debug menu item

但在命令行中使用LLDB我们能获取到更多更详细的调试信息。

以断点列表为例，在Debug Navigator中你会看到一个方法名，断点处代码所处行数，以及这个断点是否有效：

虽然这样看起来不错，但通过LLDB命令breakpoint list能带给你更多像执行次数或者地址一类的信息：

(lldb) breakpoint list
Current breakpoints:
1: file = '/Users/michal/Developer/Swift/Altimeter/Altimeter/ViewController.swift', line = 72, locations = 1, resolved = 1, hit count = 1
 
  1.1: where = Altimeter`Altimeter.ViewController.startAltimeter (Altimeter.ViewController)() -> () + 712 at ViewController.swift:72, address = 0x00000001000e86b4, resolved, hit count = 1 
 
  ...

通过添加像-v这样的参数我们能获取到更详尽的输出结果。要想了解所有的参数请输入：

(lldb) help breakpoint list

如果你想着能得到更多锻炼，尝试与breakpoint enable和breakpoint disable这样的子命令共舞：

(lldb) breakpoint disable //disables all
(lldb) breakpoint disable 1.1 //disables just one place
(lldb) breakpoint enable //enables all
...

设置简单的和复杂的断点

当使用Xcode时我们习惯在一个指定的文件的某一行设置断点。命令行的LLDB不仅仅提供了这一种类型的断点。让我们来看一下下面这些例子，每一个例子展示了简短而完整的版本：

• 在一个文件的指定行设置断点：

  (lldb) breakpoint set --file ViewController.swift --line 26
  (lldb) breakpoint set -f ViewController.swift -l 26

• 在每个方法处设立断点：

  (lldb) breakpoint set --selector viewDidLoad
  (lldb) breakpoint set -S viewDidLoad

• 在每一个方法名设立断点：

  (lldb) breakpoint set --name stringToDate
  (lldb) breakpoint set -n stringToDate

• 设置匹配regexp方法名字的断点：

  (lldb) breakpoint set --source-pattern-regexp 'Manager' -file ViewController.swift
  (lldb) breakpoint set -p 'Manager' -f ViewController.swift

• 设置一个在第一次停止后就删除的断点：

  (lldb) breakpoint set <other_params> --one-shot
  (lldb) breakpoint set <other_params> -o

当然，这只是命令行所能做到的一小部分。想了解设置断点的更多信息请输入：

(lldb) help breakpoint set

调试会话的导航

在Xcode里调试的时候你一定能熟练运用'continue'，'step in'，'step out'和'step over'按钮。对于LLDB命令来说要怎么完成同样的事呢？

(lldb) thread continue
(lldb) thread step-in
(lldb) thread step-out
(lldb) thread step-over

像往常一样，通过thread的help命令你会发现更多的参数。

其它被选出的小技巧

我们还能通过命令行完成些什么操作呢？让我们一探究竟吧。

类型格式化

你可能会对调试区（Debug Area）中的'View Value As比较熟悉。它的作用是快速改变一个给定值的展示样式：

如果你想一直把布尔变量用二进制格式显示呢？看看用LLDB是如何完成这个任务的：

(lldb) print isAltimeterRunning.value
(Builtin.Int1) $R2 = false
(lldb) type format add --format decimal Builtin.Int1
(lldb) print isAltimeterRunning.value
(Builtin.Int1) $R3 = 0

我们能额外了解到的是Swift的bool是Builtin.Int1类型。不得不说LLDB的类型格式化对于Swift的类型来说并不是很友好。类型名字必须完全匹配。类型格式化对于老的Cocoa对象和Obj-C/C支持的更好。

类型摘要

从我们关于输出调试法（print debugging）的博文中我们知道了如何使用CustomStringConvertible去获得有意义的调试信息。这同样能应用在LLDB上。为了让这看起来简单，我们用Int来举例子。这就是我们能在调试区经常看到的样子：

让我们添加一个类型摘要，把它显示到控制台上：

(lldb) type summary add -s "natural=${var.value} octal=${var.value%o} hex=${var.value%x}" Int
(lldb) frame variable integer
(Int) integer = 4095 natural=4095 octal=07777 hex=0x00000fff

当我们重新查看调试区时就能看到我们自定义的信息：

多行表达式模式

当使用LLDB调试时我们手握功能强大的编译器。开发它的潜力最好的方式是使用expression命令进入多行模式。在LLDB中输入expression，回车：

(lldb) expression
Enter expressions, then terminate with an empty line to evaluate:
1 struct compass{var direction = "N"; var angle = 16.5}
2 var c = compass()
3 print(c)
4 
(compass #1)(direction: "N", angle: 16.5)
(lldb) 

线程返回栈

当调试线程时我们经常使用Debug Navigator (⌘ + 5)：

通过一行命令就能达到同样的效果，甚至得到更详尽的线程返回栈的打印：

(lldb) thread backtrace all

错误展开

一个额外需要记住的东西是在LLDB中执行的表达式会影响我们执行过的代码。如果你在LLDB中修改了变量的值，当继续执行的时候这个变量的值仍是被修改过的。

更有甚者一些表达式可能会引起程序崩溃。通常来说如果造成了崩溃程序的状态就被清空了。然而有时候我们想要看一下这些状态。

想象一下减少一个var integer:UInt = 10变量：

(lldb) expression while integer <= 0 {integer--}
error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0).
The process has been returned to the state before expression evaluation.

我们获得了一个错误但我们依然能够继续执行。

要改变这个问题我们给表达式设置一个--unwind-on-error=0参数：

(lldb) expression --unwind-on-error=0 -- while integer <= 0 {integer--}
error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0).
The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.

这样我们就得到了真正导致的崩溃原因。

查找未格式化的变量

在类型摘要例子中我们尽我们所能得到了一个不错的格式化输出，使用了frame variable命令来显示。而有些时候我们想做的却恰恰相反-原始的值。让我们看下这里面的区别：

(lldb) frame variable self.isAltimeterRunning
(Bool) self.isAltimeterRunning = false
 
(lldb) frame variable --raw self.isAltimeterRunning
(Swift.Bool) self.isAltimeterRunning = {
  value = 0
}

这也解释了很多Swift的结构体类型是如何设置的。它们有一个value变量。挖掘更深入之后我们能看到Bool类型背后的真实类型：

(lldb) frame variable self.isAltimeterRunning.value
(Builtin.Int1) self.isAltimeterRunning.value = 0

它是Int1类型-一个一比特的整型。如果你想要知道更多关于解包Swfit Bool类型和其他类型请看SwiftUnboxed。--raw参数同样适用于窥探Swift的optional和nested optional。

就是这样！

希望你注意到了在命令行中使用LLDB命令的优点。这篇文章只是摸索了其中的冰山一角。你能在LLDB Documentation阅读有关lldb的文章。同样也去看下他们的教程。

苹果有一个quick start让开发者入门。同样有很多WWDC的视频教程：

• WWDC 2012: Debugging with LLDB

• WWDC 2014: Advanced Swift debugging in LLDB

• WWDC 2014: Introduction to LLDB and the Swift REPL

• WWDC 2015: What’s new in LLDB

最后值得一提的是，objc.io对LLDB做了很好的总结。

2016年1月21日更新

我是否需要一遍遍输入所有的命令？

如果你对有效的在命令行使用LLDB依旧没什么信心，你可能会想看一下.lldbinit。这是一个在你home路径下的文件。它包含了一系列LLDB命令。要创建你自己的文件在终端中执行以下命令：

michal$ cd ~/
michal$ touch .lldbinit
michal$ chmod +x .lldbinit

然后你就能用一系列每次LLDB启动时候要运行的命令来填充.lldbinit文件。例如：

breakpoint set -n malloc -N memory 
breakpoint set -n free -N memory
breakpoint disable memory

以上命令在malloc和free方法出设置断点并给他们一个通用的名字'memory'。这些断点是被禁止的，所以它们并不会干扰到你，但是如果你想调试内存相关的东西时它们尽在掌控。要让这些断点生效只需要修改文件最后一行或者在运行时输入下面这行命令：

(lldb) breakpoint enable memory

请观看WWDC 2015: What’s new in LLDB视频获得更多细节。

更多有用的命令

在上面提到的的WWDC视频中，你能发现很多很有用的命令，例如：

• type lookup命令：

  (lldb) type lookup CLLocation
  @available(iOS 2.0, *)
  @objc class CLLocation : ObjectiveC.NSObject, NSCopying, NSSecureCoding {
    @objc deinit  {
    }
    @objc init(latitude: CoreLocation.CLLocationDegrees, longitude: CoreLocation.CLLocationDegrees)
    ...

• 给Objc/Swift语言设置异常断点：

  (lldb) breakpoint set -E objc
  (lldb) breakpoint set -E swift

• 给某一个指定类型设置断点：

  (lldb) breakpoint set -E -O EnumError

• 最后给极少数热爱者一些福利。一个memory命令：

  (lldb) po locationMgr
  <CLLocationManager: 0x7af76280>
   
  (lldb) memory read 0x7af76280
  0x7af76280: 40 4a 17 00 60 63 f7 7a 00 00 00 00 00 00 00 00  @J..`c.z........
  0x7af76290: 33 75 af 37 20 76 af 47 03 00 00 00 00 00 00 00  3u.7 v.G........

  它的真正的威力当你查看C数组或char* 字符串才能体现。