LLDB: anong uri ng debugger ito, mga pangunahing utos at aplikasyon sa pag-develop ng iOS

Ano ang LLDB at paano ito binuo

LLDB — ay isang debugger na may open source, binuo sa mga library ng LLVM project. Pinalitan nito ang GDB sa Xcode 5 at mula noon ay naging pangunahing tool sa pag-debug para sa buong Apple ecosystem. Hindi tulad ng monolithic GDB, ang LLDB ay ipinatupad bilang isang set ng mga nagtutulungang library: bawat function — mula sa pag-parse ng mga expression hanggang sa pagtatrabaho sa memorya — ay nakahiwalay sa isang hiwalay na module, na nagpapadali sa pagpapanatili at pagpapalawak.

Ang mga pangunahing kakayahan ng LLDB ay kinabibilangan ng: pag-set ng breakpoints ng anumang uri, watchpoints para sa pagsubaybay ng mga pagbabago sa variable, inspeksyon ng memorya at rehistro, step-by-step na pagpapatupad, pag-evaluate ng mga arbitrary na expression sa konteksto ng isang naka-pause na programa at pagpapatupad ng Python scripts para sa automation. Ayon sa repositoryo ng LLVM, sinusuportahan ng LLDB ang higit sa 200 utos ng pag-debug at tugma sa mga format na DWARF at Mach-O — ang mga pangunahing format ng impormasyon sa pag-debug sa Apple ecosystem.

Isang mahalagang bentahe ng LLDB ay ang malalim na integrasyon sa Clang. Dahil sa paggamit ng parehong compiler para sa pag-parse at pag-compile ng source code, maaaring i-evaluate ng LLDB ang C++ at Objective-C expression na may katumpakan na hindi maabot ng GDB. Para sa pag-debug ng Swift, gumagamit ang LLDB ng hiwalay na module na Swift Language Runtime, na nakakaunawa sa semantika ng wika: mga opsyonal na tipo, protocol, generics at pamamahala ng memorya sa pamamagitan ng ARC.

Kasaysayan at ebolusyon

Ang unang bersyon ng LLDB ay lumitaw noong 2010 bilang bahagi ng LLVM 2.8. Pagsapit ng 2013, ganap nitong pinalitan ang GDB sa Xcode. Noong 2019 sa paglabas ng Xcode 11, nakatanggap ang LLDB ng suporta para sa Swift Error Breakpoints at pinahusay na parser ng expression para sa Swift. Ayon sa Apple, simula sa iOS 14, ang buong debugging stack para sa simulator ay gumagana rin sa pamamagitan ng LLDB, na nagpapatunay sa katayuan nito bilang pangunahing debugging tool ng platform.

Arkitektura ng LLDB: mga module at component

Arkitektura ng LLDB ay binuo sa prinsipyo ng microservices: bawat subsystem ay umiiral bilang isang hiwalay na library (dylib), na konektado sa iba sa pamamagitan ng isang karaniwang API. Ito ang nagtatangi nito mula sa GDB, kung saan ang lahat ng function ay pinagsama sa isang binary file. Ang modular na istraktura ay nagpapahintulot sa independiyenteng paggamit ng mga component ng LLDB — halimbawa, ang expression parser ay maaaring i-embed sa isang IDE nang hindi kinokonekta ang buong debugger.

LLDB at dSYM debugging symbols

dSYM — ay mga file ng debugging information na binuo ng Xcode sa panahon ng pag-compile. Ginagamit sila ng LLDB para i-map ang machine code sa source code: kung walang dSYM, ang debugger ay nagpapakita lamang ng mga memory address sa halip na mga pangalan ng function at linya ng code. Para sa mga application mula sa App Store, ang dSYM file ay hiwalay na ina-upload sa Apple server at ginagamit para sa simbolisasyon ng crash-log na natanggap mula sa mga user sa pamamagitan ng CrashReporter.

(lldb) target create MyApp.app
(lldb) image list MyApp
MyApp - "/path/to/MyApp.app/MyApp" (arm64)
(lldb) image lookup -n fetchUserData
Address: MyApp[0x1000a3b40] (MyApp.__TEXT.__text + 12352)
Summary: `ViewController.fetchUserData()` at ViewController.swift:42

Mga pangunahing utos ng LLDB para sa pag-debug

Mga utos ng LLDB ay nahahati sa ilang kategorya: pamamahala ng pagpapatupad, pagtatrabaho sa breakpoints, inspeksyon ng data at pagmamanipula ng memorya. Hindi tulad ng Xcode GUI, ang LLDB console ay nagbibigay ng ganap na kontrol sa pag-debug at nagpapahintulot sa pagpapatupad ng mga operasyon na hindi available sa pamamagitan ng graphical interface — halimbawa, pagbabago ng halaga ng variable on the fly o maramihang pag-edit ng breakpoints.

Mga utos ng pamamahala ng pagpapatupad

Continue, Step Over, Step Into, Step Out — ang batayan ng debugging cycle. continue ay nagpapatuloy ng pagpapatupad hanggang sa susunod na breakpoint. step over ay nag-execute ng kasalukuyang linya nang buo. step into ay pumapasok sa loob ng tinatawag na method. step out ay nagtatapos sa kasalukuyang function at ibinabalik ang kontrol sa tumatawag na code. Bukod pa rito, mayroong step with type filter — hakbang hanggang sa isang tinukoy na uri ng data.

(lldb) thread backtrace          # Ipakita ang call stack
* thread #1, queue = 'com.apple.main-thread'
    frame #0: 0x1000a3b40 ViewController`fetchUserData()
    frame #1: 0x1000a2000 ViewController`viewDidLoad()
    frame #2: 0x1a2b345 UIKit`UIViewController.loadView()
(lldb) frame variable          # Ipakita ang mga local variable
(Int) userId = 42
(String) endpoint = "https://api.example.com/user/42"
(lldb) thread step-over        # Step Over
(lldb) thread step-in          # Step Into

Inspeksyon ng data at mga formatter

Nagbibigay ang LLDB ng mga utos para sa pagtingin ng data sa anumang format: memory read, frame variable, target variable. Ang espesyal na syntax na po (print object) ay tumatawag sa debugDescription para sa Objective-C object at description para sa Swift types. Ang custom na mga formatter ay itinatakda sa pamamagitan ng type summary add — kapaki-pakinabang para sa pag-debug ng mga kumplikadong istraktura tulad ng CGRect o IndexPath.

(lldb) po userProfile           # Output ng paglalarawan ng object
<UserProfile: 0x600000c4b80>
  - name: "John"
  - age: 30
  - email: "john@example.com"
(lldb) expression userProfile.age = 31    # Baguhin ang halaga
(Int) $R0 = 31
(lldb) memory read 0x600000c4b80 0x600000c4bc0
0x600000c4b80: 6a 6f 68 6e 00 00 00 00 1e 00 00 00 00 00 00 00

Pag-evaluate ng mga expression at inspeksyon ng mga object

Pag-evaluate ng mga expression sa LLDB ay isa sa pinakamakapangyarihang function na wala sa GDB noong panahon ng dominasyon nito. Maaaring i-execute ng LLDB ang arbitrary na code sa C, Objective-C, C++ at Swift sa konteksto ng isang naka-pause na programa, kabilang ang pagtawag ng mga method, paggawa ng mga object at pagbabago ng estado. Ito ay nagpapahintulot sa pagsubok ng mga hypothesis nang hindi nagre-restart ng application at nagre-recompile.

Mga utos na expression at po

Ang utos na expression ay nag-co-compile at nag-e-execute ng isang expression sa runtime ng nade-debug na proseso. Ang flag na -O (object description) ay tumatawag sa po. Para sa multi-line na expression, gamitin ang expression -l Swift --. Nag-co-compile ang LLDB ng code on the fly sa pamamagitan ng Clang o Swift Compiler, isinasama ang resulta sa kasalukuyang konteksto at ibinabalik ang halaga. Ayon sa Apple, ang expression ay naco-compile sa loob ng 10–50 ms depende sa pagiging kumplikado.

(lldb) expr -l Swift -- UIAlertController(title: "Test", message: nil,
  preferredStyle: .alert)
(lldb) expr let $arr = [1, 2, 3].map { $0 * 2 }
(lldb) po $arr
▿ 3 elements
  - 0 : 2
  - 1 : 4
  - 2 : 6

Pagbabago ng mga object on the fly

Ang LLDB ay nagpapahintulot hindi lamang magbasa, kundi pati na rin magbago ng estado ng mga object at variable habang nagde-debug. Ito ay kritikal para sa pagsubok ng mga edge case: maaaring itakda ang halaga ng variable sa nil, baguhin ang kulay ng UI element o palitan ang tugon ng server nang direkta sa debugger, nang hindi nagre-recompile at nagre-restart. Ang teknik ay malawakang ginagamit sa pag-develop ng mga laro at application na may mahabang flow, kung saan ang pag-restart ay tumatagal ng maraming oras.

(lldb) expr self.label.text = @"Updated"
(lldb) expr -l Swift -- (self as! UIViewController).view.backgroundColor = .red
(lldb) expr let $snapshot = self.view.debugQuickLookObject()

Pag-script sa Python sa LLDB

Python API ng LLDB ay nagpapahintulot sa pagsulat ng mga script para sa automation ng debugging. Sa pamamagitan ng Python, maaaring gumawa ng custom na mga utos, magproseso ng breakpoint event, bumuo ng mga ulat at kahit na baguhin ang pag-uugali ng debugger. Ang built-in na Python 3 interpreter ay tumatakbo nang direkta sa loob ng LLDB, na may access sa buong debugging API sa pamamagitan ng module na lldb.

Paggawa ng custom na utos

Ang isang bagong LLDB utos ay maaaring irehistro sa pamamagitan ng dekorador na @classmethod sa isang Python script. Pagkatapos i-import ang script, ang utos ay nagiging available bilang isang built-in na utos. Halimbawa, ang utos na printvars ay maaaring magpakita ng lahat ng variable ng kasalukuyang frame kasama ang kanilang mga tipo at halaga, na naka-format para sa isang partikular na proyekto. Ang automation ay nagbabawas ng oras ng tipikal na debugging operations ng 60–80%, ayon sa isang survey ng iOS developers sa Stack Overflow.

import lldb

class PrintVarsCommand:
    @classmethod
    def register_class(cls, debugger, _):
        handler = PrintVarsCommand()
        debugger.HandleCommand('command script add -c \
            print_vars.PrintVarsCommand printvars')

    def __call__(self, debugger, command, exe_ctx, result):
        frame = exe_ctx.frame
        for var in frame.variables:
            result.AppendMessage(f"{var.name}: {var.type} = {var.value}")

Pagproseso ng breakpoint event

Sa pamamagitan ng Python API, maaaring mag-attach ng script sa pag-trigger ng breakpoint. Mag-set ng breakpoint, pagkatapos ay i-execute ang breakpoint command add at tukuyin ang isang Python function. Ito ay nagpapahintulot ng awtomatikong pag-log ng estado, pagpapadala ng data sa analytics o pag-check ng mga invariant nang walang manual na interbensyon. Ayon sa LLVM, ang pamamaraang ito ay ginagamit sa imprastraktura ng Apple para sa pagkolekta ng mga sukatan ng pagganap sa yugto ng pag-develop.

(lldb) breakpoint set -f Model.swift -l 100
(lldb) breakpoint command add 1 -s python -o "frame = exe_ctx.frame;
  print([var.name for var in frame.variables])"

REPL mode at playground

REPL (Read-Eval-Print Loop) — ang interactive na mode ng LLDB, na tinatawag sa utos na lldb --repl o sa pamamagitan ng Xcode Debug Console. Sa REPL, maaaring mag-execute ng code sa Swift o C tulad ng sa playground, na may agarang feedback. Nag-co-compile ang LLDB ng bawat linya, ini-execute ito at ipinapakita ang resulta — ito ay maginhawa para sa pag-eksperimento sa API, pag-prototype ng mga algorithm at pag-aaral ng mga bagong kakayahan ng wika nang hindi gumagawa ng proyekto.

(lldb) --repl
1> let numbers = [1, 2, 3, 4, 5]
2> numbers.filter { $0 % 2 == 0 }
$R0: [Int] = 2 values {
  [0] = 2
  [1] = 4
}
3> let result = numbers.reduce(0, +)
$R1: Int = 15

Sinusuportahan din ng REPL mode ang pag-load ng mga module at framework sa pamamagitan ng import. Halimbawa, ang import UIKit sa REPL ay naglo-load ng buong UIKit library, at maaaring gumawa ng mga UI element, suriin ang constraint at subukan ang mga animation. Ito ay isang natatanging kakayahan para sa mga iOS developer, hindi available sa GDB — debugging at prototyping sa iisang kapaligiran.

Paggamit ng REPL para sa pag-aaral ng Swift

Dahil sa integrasyon sa Swift Compiler, ang LLDB REPL ay ginagamit sa mga kurso ng Apple para sa pagtuturo ng Swift. Maaaring mag-execute ang mga estudyante ng code linya sa linya, makita ang mga tipo at resulta, nang hindi naaabala sa pag-configure ng proyekto. Ang pamamaraang ito ay naaayon sa Active Learning na pamamaraan, kung saan ang interactive na feedback ay nagpapabilis ng pag-absorb ng materyal ng 40% ayon sa pananaliksik sa larangan ng Computer Science Education.