forked from OSchip/llvm-project
				
			
		
			
				
	
	
		
			64 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			HTML
		
	
	
		
			Executable File
		
	
	
			
		
		
	
	
			64 lines
		
	
	
		
			2.7 KiB
		
	
	
	
		
			HTML
		
	
	
		
			Executable File
		
	
	
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 | 
						|
<html xmlns="http://www.w3.org/1999/xhtml">
 | 
						|
<head>
 | 
						|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 | 
						|
<link href="style.css" rel="stylesheet" type="text/css" />
 | 
						|
<title>LLDB Goals</title>
 | 
						|
</head>
 | 
						|
 | 
						|
<body>
 | 
						|
    <div class="www_title">
 | 
						|
      The <strong>LLDB</strong> Debugger
 | 
						|
    </div>
 | 
						|
    
 | 
						|
<div id="container">
 | 
						|
	<div id="content">
 | 
						|
         <!--#include virtual="sidebar.incl"-->
 | 
						|
		<div id="middle">
 | 
						|
			<div class="post">
 | 
						|
				<h1 class ="postheader">Goals</h1>
 | 
						|
				<div class="postcontent">
 | 
						|
 | 
						|
					  <p>The current state of the art in open source debuggers are that
 | 
						|
					     they work in the common cases for C applications, but don't
 | 
						|
					     handle many "hard cases" properly.  For example, C++ expression
 | 
						|
					     parsing, handling overloading, templates, multi-threading, and
 | 
						|
					     other non-trivial scenarios all work in some base cases, but
 | 
						|
					     don't work reliably.</p>
 | 
						|
 | 
						|
					  <p>The goal of LLDB is to provide an amazing debugging experience that "just
 | 
						|
					      works".  We aim to solve these long-standing problems where debuggers get
 | 
						|
					      confused, so that you can think about debugging your problem, not
 | 
						|
					      about deficiencies in the debugger.</p>
 | 
						|
 | 
						|
					  <p>With a long view, there is no good reason for a debugger to
 | 
						|
					      reinvent its own C/C++ parser, type system, know all the
 | 
						|
					      target calling convention details, implement its own disassembler,
 | 
						|
					      etc.  By using the existing libraries vended by the LLVM
 | 
						|
					      project, we believe that many of these problems will be defined
 | 
						|
					      away, and the debugger can focus on important issues like
 | 
						|
					      process control, efficient symbol reading and indexing, thread
 | 
						|
					      management, and other debugger-specific problems.</p>
 | 
						|
 | 
						|
					  <p>Some more specific goals include:</p>
 | 
						|
 | 
						|
					  <ul>
 | 
						|
					  <li>Build libraries for inclusion in IDEs, command line tools, and
 | 
						|
					      other analysis tools</li>
 | 
						|
					  <li>High performance and efficient memory use</li>
 | 
						|
					  <li>Extensible: Python scriptable and use a plug-in architecture</li>
 | 
						|
					  <li>Reuse existing compiler technology where it makes sense</li>
 | 
						|
					  <li>Excellent multi-threaded debugging support</li>
 | 
						|
					  <li>Great support for C, Objective-C and C++</li>
 | 
						|
					  <li>Retargetable to support multiple platforms</li>
 | 
						|
					  <li>Provide a base for debugger research and other innovation</li> 
 | 
						|
					  </ul>
 | 
						|
                </div>
 | 
						|
          	<div class="postfooter"></div>
 | 
						|
                </div>
 | 
						|
      	</div>
 | 
						|
	</div>
 | 
						|
</div>
 | 
						|
</body>
 | 
						|
</html>
 |