A Life of breakpoint
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

A Life of breakpoint

on

  • 1,818 views

 

Statistics

Views

Total Views
1,818
Views on SlideShare
1,803
Embed Views
15

Actions

Likes
1
Downloads
25
Comments
0

1 Embed 15

https://twitter.com 15

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

A Life of breakpoint Presentation Transcript

  • 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?
  • 11. Architecture
  • 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.)
  • 31. Questions?