SlideShare a Scribd company logo

A Life of breakpoint

•Download as PPT, PDF•
•
Hajime Morrita
Hajime Morrita

This document provides an overview of LLDB, an open-source debugger developed by Apple. It discusses LLDB's architecture, how it uses Clang and is scriptable/pluggable. It also summarizes how LLDB sets breakpoints, evaluates expressions by running on the target process, and prints structured variables using Clang type representations. Testing for LLDB consists of around 20 test cases written in Python. There is opportunity for external contributors to help with areas like testing and improving the CLI.

1 of 31
Life of breakpoint or an introduction to LLDB internal 2010/07/25 MORITA Hajime
LLDB? http:// lldb . llvm .org/ An open-source debugger, developed by Apple . Announced at WWDC2010. Will be used by XCode 4.0. An LLVM subproject, as the domain name implies.
Features and Highlights Written in C++ (to be LLVM family) Scripting aware  SWIG API. Designed as a library ,not as a CLI program. (It has one, though.) Using Clang in some parts. Clang is C/C++/Obj-C Frontend for LLVM Has  pluggable parts
Interesting facts Code size  200k lines (vs. 1000k lines for gdb) Has LLDB .framework (vs. *.a for LLVM) Currently 13 different commiters found Some are gdb-apple folks Others from llvm, clang, llvm-gcc 2 external contributors , 1 ex-intern   Focused on iOS ( SpringBoard ) Many #idef __arm__ codepaths. API classes are named as "SBXxx" Does not have unit-tests .  some scripting-based tests. Looks  far  from 1.0 release. Missing features, frequent crashes....
How far from 1.0 What isn't there yet: Regression test suite Operating system support hasn't been fully modularized yet Blocks support Calling functions in expressions Objective-C 2.0 Support: Printing properties, synthetic properties, Objective-C expressions, KVO, dynamic types, dot syntax, runtime data C++ support: Method access, handling demangled names, dynamic types Exception support: Breaking by name, thrown object, thrower http://lldb.llvm.org/status.html
How far from 1.0 ProcessMacOSX::EnableBreakpoint (BreakpointSite *bp_site) {      ....      if (bp_site->HardwarePreferred())      {          // FIXME: This code doesn't make sense .  ...        //        ThreadMacOSX *thread = (ThreadMacOSX *)m_thread_list.FindThreadByID(bp_site->GetThreadID()).get(); //        if (thread) //        { //            bp_site->SetHardwareIndex (thread->SetHardwareBreakpoint(bp_site)); //            if (bp_site->IsHardware()) //            { //                bp_site->SetEnabled(true); //                return error; //            } //        }      }      // Just let lldb::Process::EnableSoftwareBreakpoint() handle everything...      return EnableSoftwareBreakpoint (bp_site); }
Questions arise What is  Clang  used for? What part is scriptable ? What part is pluggable ?  But before these.... How we can play with it? How code is organized ? How debugger works so far?
Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far?
Play with LLDB $ svn co http://llvm.org/svn/llvm-project/lldb/trunk $ cd trunk   ... setup code signing ... see docs/code-signing.txt $ xcodebuild -project lldb.xcodeproj -configuration Debug $ ./build/Debug/lldb # invoking CLI client CAUTION: Will checkout and build LLVM!
Questions arise What is Clang used for? What part is scriptable? What part is pluggable ? But before these.... How we can play with it? How code is organized ? How debugger works so far?
Architecture
Architecture (contd.) Pluggable parts: Target : {Process, Thread, ...} for Mac OS, Linux, gdb Symbol : for DWARF, SYMTAB ObjectFile : for ELF, Mach-O API: SWIG compatible headers Pimpl-style separation from internal  Don't have CPU simulators (gdb has it.) Modules are heavily Iter-dependent.
Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far?
Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far? Breakpoint Eval/Print
To set a breakpoint, we should ... Before process launch: Read Symbols from object files to launch .... Suspend a target process Using special system calls Find function locations from Symbols. Symbol informations are from object files Map that locations to addresses in target process Set breakpoints there Rewrite the code to 0xcc (sw bp) Set the address to the special register (hw bp) Resume suspended
LLDB representation of breakpoints
System-calls around breakpoint Launching/stopping a process:  posix_spawnp(), kill() Suspending/Resuming: task_suspend(), task_resume()  Writing breakpoint bytes: mach_vm_write() See: tools/debugserver/source/MacOSX/MachTask.cpp tools/debugserver/source/MacOSX/MachVMMemory.cpp The book.
Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far? Breakpoint Eval/Print
Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far? Breakpoint Eval/Print
Evaluating Expression It's just a yet another interpreter, except: Data and code stay in the target process . Type definitions are in the object files .
Evaluating expression: 2 Paths "void ___clang_expr(void *___clang_arg) {" + text + "}" @target @host
DWARF Expression An virtual instruction set (stack machine style) Defined in DWARF3 standard or later LLDB implementing An interpreter for DWARF expression. Clang AST to DWARF expression conversion. (not LLVM backend.) Using LLVM to invoke target functions. In DWARF Version 2, all DWARF expressions were called "location expressions", whether they computed a location (address, register) or not.  (from Dwarf3.pdf)
Evaluating Expr: some questions How to lookup variables in the exp? Clang provides hooks, LLDB takes them. How to run a compiled function? Write the code to the target memory. Troubles around linking.  How to get the result of expression? Modify the AST to store the last stmt. Works well? No. It crashes early and often.
Printing structured variables Reconstruct Clang's type representations from DWARF entries Recursively traverses the object with it. Doesn't looks to work yet. But code is there...
Questions arise What is Clang used for? What part is scriptable ? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far?
Scriptability via SWIG   Process, Thread, Symbol, Type, Value, Debugger  ... 2 entry points: From a standalone program. From the CLI interpreter. Integrations is not enough yet. (cannot print WTF::Vector from CLI side.)
Other topics Testing External contribution
Testing ~20 test cases (publicly available) Written over Python binding
class TestClassTypes( lldbtest.TestBase ):      ...      def test_function_types(self):          """Test 'callback' has function ptr type, then ..."""          res = self.res          exe = os.path.join(os.getcwd(), "a.out")          self. ci.HandleCommand ( "file " + exe , res)          self.assertTrue( res.Succeeded() )          # Break inside the main.          self. ci.HandleCommand ( "breakpoint set -f main.c -l 21" , res)          self.assertTrue( res.Succeeded() )          self.assertTrue( res.GetOutput() .startswith(              "Breakpoint created: 1: file ='main.c', line = 21, ..." ))          self. ci.HandleCommand ( "run" , res)          time.sleep(0.1)          self.assertTrue( res.Succeeded() )      ...          # The stop reason of the thread should be breakpoint.          self. ci.HandleCommand ( "thread list" , res)          print "thread list ->", res.GetOutput()          self.assertTrue(res. Succeeded() )          self.assertTrue(res. GetOutput() .find( 'state is Stopped' ) > 0 and                          ...)      ...
External Contribution Linux porting has been started. Huge space to contribution: Testing!!! CLI improvement (What Apple folks has little interest) Reporting crashes Looks better to avoid Digging in the internal structures (will change fast) What I'd like to have as an (imaginary) contributor Non-mail-based Review process Buildbots Coding convention (currently scattered.)
Questions?

More Related Content

A Life of breakpoint

  • 1. Life of breakpoint or an introduction to LLDB internal 2010/07/25 MORITA Hajime
  • 2. LLDB? http:// lldb . llvm .org/ An open-source debugger, developed by Apple . Announced at WWDC2010. Will be used by XCode 4.0. An LLVM subproject, as the domain name implies.
  • 3. Features and Highlights Written in C++ (to be LLVM family) Scripting aware  SWIG API. Designed as a library ,not as a CLI program. (It has one, though.) Using Clang in some parts. Clang is C/C++/Obj-C Frontend for LLVM Has  pluggable parts
  • 4. Interesting facts Code size  200k lines (vs. 1000k lines for gdb) Has LLDB .framework (vs. *.a for LLVM) Currently 13 different commiters found Some are gdb-apple folks Others from llvm, clang, llvm-gcc 2 external contributors , 1 ex-intern   Focused on iOS ( SpringBoard ) Many #idef __arm__ codepaths. API classes are named as "SBXxx" Does not have unit-tests .  some scripting-based tests. Looks  far  from 1.0 release. Missing features, frequent crashes....
  • 5. How far from 1.0 What isn't there yet: Regression test suite Operating system support hasn't been fully modularized yet Blocks support Calling functions in expressions Objective-C 2.0 Support: Printing properties, synthetic properties, Objective-C expressions, KVO, dynamic types, dot syntax, runtime data C++ support: Method access, handling demangled names, dynamic types Exception support: Breaking by name, thrown object, thrower http://lldb.llvm.org/status.html
  • 6. How far from 1.0 ProcessMacOSX::EnableBreakpoint (BreakpointSite *bp_site) {      ....      if (bp_site->HardwarePreferred())      {          // FIXME: This code doesn't make sense .  ...        //        ThreadMacOSX *thread = (ThreadMacOSX *)m_thread_list.FindThreadByID(bp_site->GetThreadID()).get(); //        if (thread) //        { //            bp_site->SetHardwareIndex (thread->SetHardwareBreakpoint(bp_site)); //            if (bp_site->IsHardware()) //            { //                bp_site->SetEnabled(true); //                return error; //            } //        }      }      // Just let lldb::Process::EnableSoftwareBreakpoint() handle everything...      return EnableSoftwareBreakpoint (bp_site); }
  • 7. Questions arise What is  Clang  used for? What part is scriptable ? What part is pluggable ?  But before these.... How we can play with it? How code is organized ? How debugger works so far?
  • 8. Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far?
  • 9. Play with LLDB $ svn co http://llvm.org/svn/llvm-project/lldb/trunk $ cd trunk   ... setup code signing ... see docs/code-signing.txt $ xcodebuild -project lldb.xcodeproj -configuration Debug $ ./build/Debug/lldb # invoking CLI client CAUTION: Will checkout and build LLVM!
  • 10. Questions arise What is Clang used for? What part is scriptable? What part is pluggable ? But before these.... How we can play with it? How code is organized ? How debugger works so far?
  • 12. Architecture (contd.) Pluggable parts: Target : {Process, Thread, ...} for Mac OS, Linux, gdb Symbol : for DWARF, SYMTAB ObjectFile : for ELF, Mach-O API: SWIG compatible headers Pimpl-style separation from internal  Don't have CPU simulators (gdb has it.) Modules are heavily Iter-dependent.
  • 13. Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far?
  • 14. Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far? Breakpoint Eval/Print
  • 15. To set a breakpoint, we should ... Before process launch: Read Symbols from object files to launch .... Suspend a target process Using special system calls Find function locations from Symbols. Symbol informations are from object files Map that locations to addresses in target process Set breakpoints there Rewrite the code to 0xcc (sw bp) Set the address to the special register (hw bp) Resume suspended
  • 16. LLDB representation of breakpoints
  • 17. System-calls around breakpoint Launching/stopping a process:  posix_spawnp(), kill() Suspending/Resuming: task_suspend(), task_resume()  Writing breakpoint bytes: mach_vm_write() See: tools/debugserver/source/MacOSX/MachTask.cpp tools/debugserver/source/MacOSX/MachVMMemory.cpp The book.
  • 18. Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far? Breakpoint Eval/Print
  • 19. Questions arise What is Clang used for? What part is scriptable? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far? Breakpoint Eval/Print
  • 20. Evaluating Expression It's just a yet another interpreter, except: Data and code stay in the target process . Type definitions are in the object files .
  • 21. Evaluating expression: 2 Paths "void ___clang_expr(void *___clang_arg) {" + text + "}" @target @host
  • 22. DWARF Expression An virtual instruction set (stack machine style) Defined in DWARF3 standard or later LLDB implementing An interpreter for DWARF expression. Clang AST to DWARF expression conversion. (not LLVM backend.) Using LLVM to invoke target functions. In DWARF Version 2, all DWARF expressions were called "location expressions", whether they computed a location (address, register) or not.  (from Dwarf3.pdf)
  • 23. Evaluating Expr: some questions How to lookup variables in the exp? Clang provides hooks, LLDB takes them. How to run a compiled function? Write the code to the target memory. Troubles around linking.  How to get the result of expression? Modify the AST to store the last stmt. Works well? No. It crashes early and often.
  • 24. Printing structured variables Reconstruct Clang's type representations from DWARF entries Recursively traverses the object with it. Doesn't looks to work yet. But code is there...
  • 25. Questions arise What is Clang used for? What part is scriptable ? What part is pluggable? But before these.... How we can play with it? How code is organized? How debugger works so far?
  • 26. Scriptability via SWIG   Process, Thread, Symbol, Type, Value, Debugger  ... 2 entry points: From a standalone program. From the CLI interpreter. Integrations is not enough yet. (cannot print WTF::Vector from CLI side.)
  • 27. Other topics Testing External contribution
  • 28. Testing ~20 test cases (publicly available) Written over Python binding
  • 29. class TestClassTypes( lldbtest.TestBase ):      ...      def test_function_types(self):          """Test 'callback' has function ptr type, then ..."""          res = self.res          exe = os.path.join(os.getcwd(), "a.out")          self. ci.HandleCommand ( "file " + exe , res)          self.assertTrue( res.Succeeded() )          # Break inside the main.          self. ci.HandleCommand ( "breakpoint set -f main.c -l 21" , res)          self.assertTrue( res.Succeeded() )          self.assertTrue( res.GetOutput() .startswith(              "Breakpoint created: 1: file ='main.c', line = 21, ..." ))          self. ci.HandleCommand ( "run" , res)          time.sleep(0.1)          self.assertTrue( res.Succeeded() )      ...          # The stop reason of the thread should be breakpoint.          self. ci.HandleCommand ( "thread list" , res)          print "thread list ->", res.GetOutput()          self.assertTrue(res. Succeeded() )          self.assertTrue(res. GetOutput() .find( 'state is Stopped' ) > 0 and                          ...)      ...
  • 30. External Contribution Linux porting has been started. Huge space to contribution: Testing!!! CLI improvement (What Apple folks has little interest) Reporting crashes Looks better to avoid Digging in the internal structures (will change fast) What I'd like to have as an (imaginary) contributor Non-mail-based Review process Buildbots Coding convention (currently scattered.)