A Life of breakpoint

Life of breakpointor an introduction to LLDB internal

2010/07/25MORITA 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.

o 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

o Some are gdb-apple folkso Others from llvm, clang, llvm-gcco 2 external contributors, 1 ex-intern 

• Focused on iOS (SpringBoard)o Many #idef __arm__ codepaths.o API classes are named as "SBXxx"

• Does not have unit-tests. o some scripting-based tests.

• Looks far from 1.0 release.o Missing features, frequent crashes....

How far from 1.0What 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.0ProcessMacOSX::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 clientCAUTION: 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:o Target: {Process, Thread, ...} for Mac OS, Linux, gdbo Symbol: for DWARF, SYMTABo ObjectFile: for ELF, Mach-O

• API:o SWIG compatible headerso 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?

o Breakpointo Eval/Print

To set a breakpoint, we should ...• Before process launch:

o Read Symbols from object files to launch• ....• Suspend a target process

o Using special system calls• Find function locations from Symbols.

o Symbol informations are from object files• Map that locations to addresses

in target process• Set breakpoints there

o Rewrite the code to 0xcc (sw bp)o 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?

o Breakpointo 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?

o Breakpointo 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 implementingo An interpreter for DWARF expression.o 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?o Clang provides hooks, LLDB takes them.

• How to run a compiled function?o Write the code to the target memory.o Troubles around linking. 

• How to get the result of expression?o Modify the AST to store the last stmt.

• Works well?o No. It crashes early and often.

Printing structured variables• Reconstruct Clang's type representations

from DWARF entrieso 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:

o From a standalone program.o From the CLI interpreter.o 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:

o Testing!!!o CLI improvement (What Apple folks has little interest)o Reporting crashes

• Looks better to avoido Digging in the internal structures (will change fast)

• What I'd like to have as an (imaginary) contributoro Non-mail-based Review processo Buildbotso Coding convention (currently scattered.)

Questions?