[譯] LLDB 基礎

時間 2019-11-06

標籤 lldb 基礎简体版

原文原文鏈接

原文連接：https://swifting.io/blog/2016/02/19/6-basic-lldb-tips/
原做者：Michał Wojtysiakhtml

長話短說

在開發了幾年的iOS應用後，我對LLDB調試器的使用已經趨於最小：ios

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

以上幾乎就是我使用的所有了。這並不值得驕傲。設置一個斷點，而後使用po命令。我知道po是'print object（輸出對象）'的意思，而且能用它來計算表達式。我須要更先進的工具來幫我應對不得不處理的複雜難題。git

讓咱們開始吧！express

探究LLDB工做區

你總可以在調試的時候輸入一個help命令：swift

(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還不賴嘛，還不賴。xcode

LLDB必需要配合Xcode才能使用嗎？

固然。。。不是咯！咱們並不須要依賴Xcode的調試區域（Debug Area）。咱們可以很輕易地從終端啓動LLDB。在此以前咱們須要先搭建一個app去模擬相應的環境。在終端切換到你的項目路徑下輸入：app

michal$ xcodebuild -sdk iphonesimulator9.2

在路徑：project_dir/build/Release-iphonesimulator/appname.app 下你就有了一個爲調試而生的 *.app 文件。iphone

如今，在不切換路徑的前提下你就可以從終端啓動LLDB了：ide

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的視頻教程：

最後值得一提的是，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視頻得到更多細節。