You've already forked linux-packaging-mono
							
							
		
			
	
	
		
			64 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
		
		
			
		
	
	
			64 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
|   | <!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> |