A step towards geting linux ppc to work (see PR 3099)

[oota-llvm.git] / docs / SourceLevelDebugging.html

diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html
index 3c9df8dc0fea433275df4c1f41791121fdc3414e..4984521f5993f7fea2ab8359b28c9c8aa92ef5b0 100644 (file)
--- a/docs/SourceLevelDebugging.html
+++ b/docs/SourceLevelDebugging.html
@@ -130,7 +130,7 @@ href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3 standard</a>).</p>
 <p>When a program is being debugged, a debugger interacts with the user and
 turns the stored debug information into source-language specific information. 
 As such, a debugger must be aware of the source-language, and is thus tied to
-a specific language of family of languages.</p>
+a specific language or family of languages.</p>
 
 </div>
 
@@ -142,7 +142,7 @@ a specific language of family of languages.</p>
 <div class="doc_text">
 <p>The role of debug information is to provide meta information normally
 stripped away during the compilation process.  This meta information provides an
-llvm user a relationship between generated code and the original program source
+LLVM user a relationship between generated code and the original program source
 code.</p>
 
 <p>Currently, debug information is consumed by the DwarfWriter to produce dwarf
@@ -175,12 +175,12 @@ source-level state of the program</b>, regardless of which LLVM optimizations
 have been run, and without any modification to the optimizations themselves.
 However, some optimizations may impact the ability to modify the current state
 of the program with a debugger, such as setting program variables, or calling
-function that have been deleted.</li>
+functions that have been deleted.</li>
 
 <li>LLVM optimizations gracefully interact with debugging information.  If they
 are not aware of debug information, they are automatically disabled as necessary
 in the cases that would invalidate the debug info.  This retains the LLVM
-features making it easy to write new transformations.</li>
+features, making it easy to write new transformations.</li>
 
 <li>As desired, LLVM optimizations can be upgraded to be aware of the LLVM
 debugging information, allowing them to update the debugging information as they
@@ -208,6 +208,24 @@ elimination and inlining), but you might lose the ability to modify the program
 and call functions where were optimized out of the program, or inlined away
 completely.</p>
 
+<p> <a href=http://llvm.org/docs/TestingGuide.html#quicktestsuite> 
+LLVM test suite </a> provides a framework to test optimizer's handling of
+debugging information. It can be run like this:</p>
+
+<div class="doc_code">
+<pre>
+% cd llvm/projects/test-suite/MultiSource/Benchmarks  # or some other level
+% make TEST=dbgopt
+</pre>
+</div>
+
+<p>
+This will test impact of debugging information on optimization passes. If
+debugging information influences optimization passes then it will be reported
+as a failure. See <a href=//llvm.org/docs/TestingGuide.html> TestingGuide</a>
+for more information on LLVM test infratsture and how to run various tests.
+</p>
+
 </div>
 
 <!-- *********************************************************************** -->
@@ -747,7 +765,7 @@ provide debug information at various points in generated code.</p>
 
 <p>This intrinsic is used to provide correspondence between the source file and
 the generated code.  The first argument is the line number (base 1), second
-argument si the column number (0 if unknown) and the third argument the source
+argument is the column number (0 if unknown) and the third argument the source
 <tt>%<a href="#format_compile_units">llvm.dbg.compile_unit</a>*</tt> cast to a
 <tt>{ }*</tt>.  Code following a call to this intrinsic will have been defined
 in close proximity of the line, column and file.  This information holds until
@@ -767,10 +785,13 @@ href="#format_common_stoppoint">lvm.dbg.stoppoint</a></tt>.</p>
 </pre>
 
 <p>This intrinsic is used to link the debug information in <tt>%<a
-href="#format_subprograms">llvm.dbg.subprogram</a></tt> to the function. It also
-defines the beginning of the function's declarative region (scope.)  The
-intrinsic should be called early in the function after the all the alloca
-instructions.  It should be paired off with a closing <tt>%<a
+href="#format_subprograms">llvm.dbg.subprogram</a></tt> to the function. It
+defines the beginning of the function's declarative region (scope). It also
+implies a call to %<tt><a
+href="#format_common_stoppoint">llvm.dbg.stoppoint</a></tt> which defines a
+source line "stop point". The intrinsic should be called early in the function
+after the all the alloca instructions.  It should be paired off with a closing
+<tt>%<a
 href="#format_common_region_end">llvm.dbg.region.end</a></tt>.  The function's
 single argument is the <tt>%<a
 href="#format_subprograms">llvm.dbg.subprogram.type</a></tt>.</p>
@@ -991,7 +1012,7 @@ another scope).</p>
 
 <p>It is worth noting that this scoping mechanism is used to control scoping of
 all declarations, not just variable declarations.  For example, the scope of a
-C++ using declaration is controlled with this couldchange how name lookup is
+C++ using declaration is controlled with this and could change how name lookup is
 performed.</p>
 
 </div>