-<p><pre>
-1. void foo() {
-2. int X = ...;
-3. int Y = ...;
-4. {
-5. int Z = ...;
-6. ...
-7. }
-8. ...
-9. }
-</pre></p>
-
-<p>
-Compiled to LLVM, this function would be represented like this (FIXME: CHECK AND
-UPDATE THIS):
-</p>
-
-<p><pre>
-void %foo() {
- %X = alloca int
- %Y = alloca int
- %Z = alloca int
- <a name="#icl_ex_D1">%D1</a> = call {}* %llvm.dbg.func.start(<a href="#impl_common_globals">%lldb.global</a>* %d.foo)
- %D2 = call {}* <a href="#impl_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D1, uint 2, uint 2, <a href="#impl_common_source_files">%lldb.compile_unit</a>* %file)
-
- %D3 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D2, ...)
- <i>;; Evaluate expression on line 2, assigning to X.</i>
- %D4 = call {}* <a href="#impl_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D3, uint 3, uint 2, <a href="#impl_common_source_files">%lldb.compile_unit</a>* %file)
-
- %D5 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D4, ...)
- <i>;; Evaluate expression on line 3, assigning to Y.</i>
- %D6 = call {}* <a href="#impl_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D5, uint 5, uint 4, <a href="#impl_common_source_files">%lldb.compile_unit</a>* %file)
-
- <a name="#icl_ex_D1">%D7</a> = call {}* %llvm.region.start({}* %D6)
- %D8 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D7, ...)
- <i>;; Evaluate expression on line 5, assigning to Z.</i>
- %D9 = call {}* <a href="#impl_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D8, uint 6, uint 4, <a href="#impl_common_source_files">%lldb.compile_unit</a>* %file)
-
- <i>;; Code for line 6.</i>
- %D10 = call {}* %llvm.region.end({}* %D9)
- %D11 = call {}* <a href="#impl_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D10, uint 8, uint 2, <a href="#impl_common_source_files">%lldb.compile_unit</a>* %file)
-
- <i>;; Code for line 8.</i>
- <a name="#icl_ex_D1">%D12</a> = call {}* %llvm.region.end({}* %D11)
- ret void
-}
-</pre></p>
-
-<p>
-This example illustrates a few important details about the LLVM debugging
-information. In particular, it shows how the various intrinsics used are woven
-together with def-use and use-def chains, similar to how <a
-href="#impl_common_anchors">anchors</a> are used with globals. This allows the
-debugger to analyze the relationship between statements, variable definitions,
-and the code used to implement the function.</p>
-
-<p>
-In this example, two explicit regions are defined, one with the <a
-href="#icl_ex_D1">definition of the <tt>%D1</tt> variable</a> and one with the
-<a href="#icl_ex_D7">definition of <tt>%D7</tt></a>. In the case of
-<tt>%D1</tt>, the debug information indicates that the function whose <a
-href="#impl_common_globals">descriptor</a> is specified as an argument to the
-intrinsic. This defines a new stack frame whose lifetime ends when the region
-is ended by <a href="#icl_ex_D12">the <tt>%D12</tt> call</a>.</p>
-
-<p>
-Representing the boundaries of functions with regions allows normal LLVM
-interprocedural optimizations to change the boundaries of functions without
-having to worry about breaking mapping information between LLVM and source-level
-functions. In particular, the inlining optimization requires no modification to
-support inlining with debugging information: there is no correlation drawn
-between LLVM functions and their source-level counterparts.</p>
-
-<p>
-Once the function has been defined, the <a
-href="#impl_common_stoppoint">stopping point</a> corresponding to line #2 of the
-function is encountered. At this point in the function, <b>no</b> local
-variables are live. As lines 2 and 3 of the example are executed, their
-variable definitions are automatically introduced into the program, without the
-need to specify a new region. These variables do not require new regions to be
-introduced because they go out of scope at the same point in the program: line
-9.
-</p>
-
-<p>
-In contrast, the <tt>Z</tt> variable goes out of scope at a different time, on
-line 7. For this reason, it is defined within <a href="#icl_ex_D7">the
-<tt>%D7</tt> region</a>, which kills the availability of <tt>Z</tt> before the
-code for line 8 is executed. Through the use of LLVM debugger regions,
-arbitrary source-language scoping rules can be supported, as long as they can
-only be nested (ie, one scope cannot partially overlap with a part of 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, and the <tt>llvm-db</tt> C++ support
-routines could use this to change how name lookup is performed (though this is
-not yet implemented).
-</p>