[llvm-commits] [llvm] r71974 - /llvm/trunk/docs/SourceLevelDebugging.html
Bill Wendling
isanbard at gmail.com
Sat May 16 22:52:41 PDT 2009
Author: void
Date: Sun May 17 00:52:39 2009
New Revision: 71974
URL: http://llvm.org/viewvc/llvm-project?rev=71974&view=rev
Log:
Formatting. Some updating of data structures. More work needs to be done to update the examples.
Modified:
llvm/trunk/docs/SourceLevelDebugging.html
Modified: llvm/trunk/docs/SourceLevelDebugging.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/SourceLevelDebugging.html?rev=71974&r1=71973&r2=71974&view=diff
==============================================================================
--- llvm/trunk/docs/SourceLevelDebugging.html (original)
+++ llvm/trunk/docs/SourceLevelDebugging.html Sun May 17 00:52:39 2009
@@ -2,6 +2,7 @@
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Source Level Debugging with LLVM</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
@@ -77,10 +78,11 @@
<div class="doc_text">
<p>This document is the central repository for all information pertaining to
-debug information in LLVM. It describes the <a href="#format">actual format
-that the LLVM debug information</a> takes, which is useful for those interested
-in creating front-ends or dealing directly with the information. Further, this
-document provides specifc examples of what debug information for C/C++.</p>
+ debug information in LLVM. It describes the <a href="#format">actual format
+ that the LLVM debug information</a> takes, which is useful for those
+ interested in creating front-ends or dealing directly with the information.
+ Further, this document provides specifc examples of what debug information
+ for C/C++.</p>
</div>
@@ -92,45 +94,45 @@
<div class="doc_text">
<p>The idea of the LLVM debugging information is to capture how the important
-pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
-Several design aspects have shaped the solution that appears here. The
-important ones are:</p>
+ pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
+ Several design aspects have shaped the solution that appears here. The
+ important ones are:</p>
<ul>
-<li>Debugging information should have very little impact on the rest of the
-compiler. No transformations, analyses, or code generators should need to be
-modified because of debugging information.</li>
-
-<li>LLVM optimizations should interact in <a href="#debugopt">well-defined and
-easily described ways</a> with the debugging information.</li>
-
-<li>Because LLVM is designed to support arbitrary programming languages,
-LLVM-to-LLVM tools should not need to know anything about the semantics of the
-source-level-language.</li>
-
-<li>Source-level languages are often <b>widely</b> different from one another.
-LLVM should not put any restrictions of the flavor of the source-language, and
-the debugging information should work with any language.</li>
-
-<li>With code generator support, it should be possible to use an LLVM compiler
-to compile a program to native machine code and standard debugging formats.
-This allows compatibility with traditional machine-code level debuggers, like
-GDB or DBX.</li>
-
+ <li>Debugging information should have very little impact on the rest of the
+ compiler. No transformations, analyses, or code generators should need to
+ be modified because of debugging information.</li>
+
+ <li>LLVM optimizations should interact in <a href="#debugopt">well-defined and
+ easily described ways</a> with the debugging information.</li>
+
+ <li>Because LLVM is designed to support arbitrary programming languages,
+ LLVM-to-LLVM tools should not need to know anything about the semantics of
+ the source-level-language.</li>
+
+ <li>Source-level languages are often <b>widely</b> different from one another.
+ LLVM should not put any restrictions of the flavor of the source-language,
+ and the debugging information should work with any language.</li>
+
+ <li>With code generator support, it should be possible to use an LLVM compiler
+ to compile a program to native machine code and standard debugging
+ formats. This allows compatibility with traditional machine-code level
+ debuggers, like GDB or DBX.</li>
</ul>
-<p>The approach used by the LLVM implementation is to use a small set of <a
-href="#format_common_intrinsics">intrinsic functions</a> to define a mapping
-between LLVM program objects and the source-level objects. The description of
-the source-level program is maintained in LLVM global variables in an <a
-href="#ccxx_frontend">implementation-defined format</a> (the C/C++ front-end
-currently uses working draft 7 of the <a
-href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3 standard</a>).</p>
+<p>The approach used by the LLVM implementation is to use a small set
+ of <a href="#format_common_intrinsics">intrinsic functions</a> to define a
+ mapping between LLVM program objects and the source-level objects. The
+ description of the source-level program is maintained in LLVM global
+ variables in an <a href="#ccxx_frontend">implementation-defined format</a>
+ (the C/C++ front-end currently uses working draft 7 of
+ the <a 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 or family of languages.</p>
+ 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 or family of languages.</p>
</div>
@@ -140,18 +142,19 @@
</div>
<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
-code.</p>
+ stripped away during the compilation process. This meta information provides
+ an 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
-information used by the gdb debugger. Other targets could use the same
-information to produce stabs or other debug forms.</p>
+ information used by the gdb debugger. Other targets could use the same
+ information to produce stabs or other debug forms.</p>
<p>It would also be reasonable to use debug information to feed profiling tools
-for analysis of generated code, or, tools for reconstructing the original source
-from generated code.</p>
+ for analysis of generated code, or, tools for reconstructing the original
+ source from generated code.</p>
<p>TODO - expound a bit more.</p>
@@ -165,52 +168,53 @@
<div class="doc_text">
<p>An extremely high priority of LLVM debugging information is to make it
-interact well with optimizations and analysis. In particular, the LLVM debug
-information provides the following guarantees:</p>
+ interact well with optimizations and analysis. In particular, the LLVM debug
+ information provides the following guarantees:</p>
<ul>
-
-<li>LLVM debug information <b>always provides information to accurately read the
-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
-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>
-
-<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
-perform aggressive optimizations. This means that, with effort, the LLVM
-optimizers could optimize debug code just as well as non-debug code.</li>
-
-<li>LLVM debug information does not prevent many important optimizations from
-happening (for example inlining, basic block reordering/merging/cleanup, tail
-duplication, etc), further reducing the amount of the compiler that eventually
-is "aware" of debugging information.</li>
-
-<li>LLVM debug information is automatically optimized along with the rest of the
-program, using existing facilities. For example, duplicate information is
-automatically merged by the linker, and unused information is automatically
-removed.</li>
-
+ <li>LLVM debug information <b>always provides information to accurately read
+ the 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 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>
+
+ <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 perform aggressive optimizations. This means that, with effort,
+ the LLVM optimizers could optimize debug code just as well as non-debug
+ code.</li>
+
+ <li>LLVM debug information does not prevent many important optimizations from
+ happening (for example inlining, basic block reordering/merging/cleanup,
+ tail duplication, etc), further reducing the amount of the compiler that
+ eventually is "aware" of debugging information.</li>
+
+ <li>LLVM debug information is automatically optimized along with the rest of
+ the program, using existing facilities. For example, duplicate
+ information is automatically merged by the linker, and unused information
+ is automatically removed.</li>
</ul>
<p>Basically, the debug information allows you to compile a program with
-"<tt>-O0 -g</tt>" and get full debug information, allowing you to arbitrarily
-modify the program as it executes from a debugger. Compiling a program with
-"<tt>-O3 -g</tt>" gives you full debug information that is always available and
-accurate for reading (e.g., you get accurate stack traces despite tail call
-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>
+ "<tt>-O0 -g</tt>" and get full debug information, allowing you to arbitrarily
+ modify the program as it executes from a debugger. Compiling a program with
+ "<tt>-O3 -g</tt>" gives you full debug information that is always available
+ and accurate for reading (e.g., you get accurate stack traces despite tail
+ call 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="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>
+ framework to test optimizer's handling of debugging information. It can be
+ run like this:</p>
<div class="doc_code">
<pre>
@@ -219,12 +223,10 @@
</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="TestingGuide.html">TestingGuide</a>
-for more information on LLVM test infrastructure and how to run various tests.
-</p>
+<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="TestingGuide.html">TestingGuide</a> for more
+ information on LLVM test infrastructure and how to run various tests.</p>
</div>
@@ -237,44 +239,45 @@
<div class="doc_text">
<p>LLVM debugging information has been carefully designed to make it possible
-for the optimizer to optimize the program and debugging information without
-necessarily having to know anything about debugging information. In particular,
-the global constant merging pass automatically eliminates duplicated debugging
-information (often caused by header files), the global dead code elimination
-pass automatically deletes debugging information for a function if it decides to
-delete the function, and the linker eliminates debug information when it merges
-<tt>linkonce</tt> functions.</p>
+ for the optimizer to optimize the program and debugging information without
+ necessarily having to know anything about debugging information. In
+ particular, the global constant merging pass automatically eliminates
+ duplicated debugging information (often caused by header files), the global
+ dead code elimination pass automatically deletes debugging information for a
+ function if it decides to delete the function, and the linker eliminates
+ debug information when it merges <tt>linkonce</tt> functions.</p>
<p>To do this, most of the debugging information (descriptors for types,
-variables, functions, source files, etc) is inserted by the language front-end
-in the form of LLVM global variables. These LLVM global variables are no
-different from any other global variables, except that they have a web of LLVM
-intrinsic functions that point to them. If the last references to a particular
-piece of debugging information are deleted (for example, by the
-<tt>-globaldce</tt> pass), the extraneous debug information will automatically
-become dead and be removed by the optimizer.</p>
+ variables, functions, source files, etc) is inserted by the language
+ front-end in the form of LLVM global variables. These LLVM global variables
+ are no different from any other global variables, except that they have a web
+ of LLVM intrinsic functions that point to them. If the last references to a
+ particular piece of debugging information are deleted (for example, by the
+ <tt>-globaldce</tt> pass), the extraneous debug information will
+ automatically become dead and be removed by the optimizer.</p>
<p>Debug information is designed to be agnostic about the target debugger and
-debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic
-machine debug information pass to decode the information that represents
-variables, types, functions, namespaces, etc: this allows for arbitrary
-source-language semantics and type-systems to be used, as long as there is a
-module written for the target debugger to interpret the information. In
-addition, debug global variables are declared in the <tt>"llvm.metadata"</tt>
-section. All values declared in this section are stripped away after target
-debug information is constructed and before the program object is emitted.</p>
+ debugging information representation (e.g. DWARF/Stabs/etc). It uses a
+ generic machine debug information pass to decode the information that
+ represents variables, types, functions, namespaces, etc: this allows for
+ arbitrary source-language semantics and type-systems to be used, as long as
+ there is a module written for the target debugger to interpret the
+ information. In addition, debug global variables are declared in
+ the <tt>"llvm.metadata"</tt> section. All values declared in this section
+ are stripped away after target debug information is constructed and before
+ the program object is emitted.</p>
<p>To provide basic functionality, the LLVM debugger does have to make some
-assumptions about the source-level language being debugged, though it keeps
-these to a minimum. The only common features that the LLVM debugger assumes
-exist are <a href="#format_compile_units">source files</a>, and <a
-href="#format_global_variables">program objects</a>. These abstract objects are
-used by a debugger to form stack traces, show information about local
-variables, etc.</p>
+ assumptions about the source-level language being debugged, though it keeps
+ these to a minimum. The only common features that the LLVM debugger assumes
+ exist are <a href="#format_compile_units">source files</a>,
+ and <a href="#format_global_variables">program objects</a>. These abstract
+ objects are used by a debugger to form stack traces, show information about
+ local variables, etc.</p>
<p>This section of the documentation first describes the representation aspects
-common to any source-language. The <a href="#ccxx_frontend">next section</a>
-describes the data layout conventions used by the C and C++ front-ends.</p>
+ common to any source-language. The <a href="#ccxx_frontend">next section</a>
+ describes the data layout conventions used by the C and C++ front-ends.</p>
</div>
@@ -284,42 +287,48 @@
</div>
<div class="doc_text">
+
<p>In consideration of the complexity and volume of debug information, LLVM
-provides a specification for well formed debug global variables. The constant
-value of each of these globals is one of a limited set of structures, known as
-debug descriptors.</p>
+ provides a specification for well formed debug global variables. The
+ constant value of each of these globals is one of a limited set of
+ structures, known as debug descriptors.</p>
<p>Consumers of LLVM debug information expect the descriptors for program
-objects to start in a canonical format, but the descriptors can include
-additional information appended at the end that is source-language specific. All
-LLVM debugging information is versioned, allowing backwards compatibility in the
-case that the core structures need to change in some way. Also, all debugging
-information objects start with a tag to indicate what type of object it is. The
-source-language is allowed to define its own objects, by using unreserved tag
-numbers. We recommend using with tags in the range 0x1000 thru 0x2000 (there is
-a defined enum DW_TAG_user_base = 0x1000.)</p>
+ objects to start in a canonical format, but the descriptors can include
+ additional information appended at the end that is source-language
+ specific. All LLVM debugging information is versioned, allowing backwards
+ compatibility in the case that the core structures need to change in some
+ way. Also, all debugging information objects start with a tag to indicate
+ what type of object it is. The source-language is allowed to define its own
+ objects, by using unreserved tag numbers. We recommend using with tags in
+ the range 0x1000 thru 0x2000 (there is a defined enum DW_TAG_user_base =
+ 0x1000.)</p>
<p>The fields of debug descriptors used internally by LLVM (MachineModuleInfo)
-are restricted to only the simple data types <tt>int</tt>, <tt>uint</tt>,
-<tt>bool</tt>, <tt>float</tt>, <tt>double</tt>, <tt>i8*</tt> and <tt> { }*
-</tt>. References to arbitrary values are handled using a <tt> { }* </tt> and a
-cast to <tt> { }* </tt> expression; typically references to other field
-descriptors, arrays of descriptors or global variables.</p>
+ are restricted to only the simple data types <tt>int</tt>, <tt>uint</tt>,
+ <tt>bool</tt>, <tt>float</tt>, <tt>double</tt>, <tt>i8*</tt> and
+ <tt>{ }*</tt>. References to arbitrary values are handled using a
+ <tt>{ }*</tt> and a cast to <tt>{ }*</tt> expression; typically
+ references to other field descriptors, arrays of descriptors or global
+ variables.</p>
+<div class="doc_code">
<pre>
- %llvm.dbg.object.type = type {
- uint, ;; A tag
- ...
- }
+%llvm.dbg.object.type = type {
+ uint, ;; A tag
+ ...
+}
</pre>
+</div>
<p><a name="LLVMDebugVersion">The first field of a descriptor is always an
-<tt>uint</tt> containing a tag value identifying the content of the descriptor.
-The remaining fields are specific to the descriptor. The values of tags are
-loosely bound to the tag values of Dwarf information entries. However, that
-does not restrict the use of the information supplied to Dwarf targets. To
-facilitate versioning of debug information, the tag is augmented with the
-current debug version (LLVMDebugVersion = 4 << 16 or 0x40000 or 262144.)</a></p>
+ <tt>uint</tt> containing a tag value identifying the content of the
+ descriptor. The remaining fields are specific to the descriptor. The values
+ of tags are loosely bound to the tag values of DWARF information entries.
+ However, that does not restrict the use of the information supplied to DWARF
+ targets. To facilitate versioning of debug information, the tag is augmented
+ with the current debug version (LLVMDebugVersion = 4 << 16 or 0x40000 or
+ 262144.)</a></p>
<p>The details of the various descriptors follow.</p>
@@ -332,34 +341,48 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_anchors">llvm.dbg.anchor.type</a> = type {
- uint, ;; Tag = 0 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- uint ;; Tag of descriptors grouped by the anchor
- }
+%<a href="#format_anchors">llvm.dbg.anchor.type</a> = type {
+ i32, ;; Tag = 0 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
+ i32 ;; Tag of descriptors grouped by the anchor
+}
</pre>
+</div>
<p>One important aspect of the LLVM debug representation is that it allows the
-LLVM debugger to efficiently index all of the global objects without having the
-scan the program. To do this, all of the global objects use "anchor"
-descriptors with designated names. All of the global objects of a particular
-type (e.g., compile units) contain a pointer to the anchor. This pointer allows
-a debugger to use def-use chains to find all global objects of that type.</p>
+ LLVM debugger to efficiently index all of the global objects without having
+ the scan the program. To do this, all of the global objects use "anchor"
+ descriptors with designated names. All of the global objects of a particular
+ type (e.g., compile units) contain a pointer to the anchor. This pointer
+ allows a debugger to use def-use chains to find all global objects of that
+ type.</p>
<p>The following names are recognized as anchors by LLVM:</p>
+<div class="doc_code">
<pre>
- %<a href="#format_compile_units">llvm.dbg.compile_units</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 17 } ;; DW_TAG_compile_unit
- %<a href="#format_global_variables">llvm.dbg.global_variables</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 52 } ;; DW_TAG_variable
- %<a href="#format_subprograms">llvm.dbg.subprograms</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 46 } ;; DW_TAG_subprogram
+%<a href="#format_compile_units">llvm.dbg.compile_units</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> {
+ i32 0,
+ i32 17
+} ;; DW_TAG_compile_unit
+%<a href="#format_global_variables">llvm.dbg.global_variables</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> {
+ i32 0,
+ i32 52
+} ;; DW_TAG_variable
+%<a href="#format_subprograms">llvm.dbg.subprograms</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> {
+ i32 0,
+ i32 46
+} ;; DW_TAG_subprogram
</pre>
+</div>
<p>Using anchors in this way (where the compile unit descriptor points to the
-anchors, as opposed to having a list of compile unit descriptors) allows for the
-standard dead global elimination and merging passes to automatically remove
-unused debugging information. If the globals were kept track of through lists,
-there would always be an object pointing to the descriptors, thus would never be
-deleted.</p>
+ anchors, as opposed to having a list of compile unit descriptors) allows for
+ the standard dead global elimination and merging passes to automatically
+ remove unused debugging information. If the globals were kept track of
+ through lists, there would always be an object pointing to the descriptors,
+ thus would never be deleted.</p>
</div>
@@ -370,37 +393,43 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> = type {
- uint, ;; Tag = 17 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_compile_unit)
- { }*, ;; Compile unit anchor = cast = (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_units</a> to { }*)
- uint, ;; Dwarf language identifier (ex. DW_LANG_C89)
- i8*, ;; Source file name
- i8*, ;; Source file directory (includes trailing slash)
- i8* ;; Producer (ex. "4.0.1 LLVM (LLVM research group)")
- bool ;; True if this is a main compile unit.
- }
-</pre>
-
-<p>These descriptors contain a source language ID for the file (we use the Dwarf
-3.0 ID numbers, such as <tt>DW_LANG_C89</tt>, <tt>DW_LANG_C_plus_plus</tt>,
-<tt>DW_LANG_Cobol74</tt>, etc), three strings describing the filename, working
-directory of the compiler, and an identifier string for the compiler that
-produced it.</p>
-
-<p> Compile unit descriptors provide the root context for objects declared in a
-specific source file. Global variables and top level functions would be defined
-using this context. Compile unit descriptors also provide context for source
-line correspondence.</p>
-
-<p> Each input file is encoded as a separate compile unit in LLVM debugging
-information output. However, many target specific tool chains prefer to encode
-only one compile unit in an object file. In this situation, the LLVM code
-generator will include debugging information entities in the compile unit
-that is marked as main compile unit. The code generator accepts maximum one main
-compile unit per module. If a module does not contain any main compile unit
-then the code generator will emit multiple compile units in the output object
-file.
+%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> = type {
+ i32, ;; Tag = 17 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_compile_unit)
+ { }*, ;; Compile unit anchor = cast = (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_units</a> to { }*)
+ i32, ;; DWARF language identifier (ex. DW_LANG_C89)
+ i8*, ;; Source file name
+ i8*, ;; Source file directory (includes trailing slash)
+ i8* ;; Producer (ex. "4.0.1 LLVM (LLVM research group)")
+ i1, ;; True if this is a main compile unit.
+ i1, ;; True if this is optimized.
+ i8*, ;; Flags
+ i32 ;; Runtime version
+}
+</pre>
+</div>
+
+<p>These descriptors contain a source language ID for the file (we use the DWARF
+ 3.0 ID numbers, such as <tt>DW_LANG_C89</tt>, <tt>DW_LANG_C_plus_plus</tt>,
+ <tt>DW_LANG_Cobol74</tt>, etc), three strings describing the filename,
+ working directory of the compiler, and an identifier string for the compiler
+ that produced it.</p>
+
+<p>Compile unit descriptors provide the root context for objects declared in a
+ specific source file. Global variables and top level functions would be
+ defined using this context. Compile unit descriptors also provide context
+ for source line correspondence.</p>
+
+<p>Each input file is encoded as a separate compile unit in LLVM debugging
+ information output. However, many target specific tool chains prefer to
+ encode only one compile unit in an object file. In this situation, the LLVM
+ code generator will include debugging information entities in the compile
+ unit that is marked as main compile unit. The code generator accepts maximum
+ one main compile unit per module. If a module does not contain any main
+ compile unit then the code generator will emit multiple compile units in the
+ output object file.</p>
+
</div>
<!-- ======================================================================= -->
@@ -410,22 +439,24 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_global_variables">llvm.dbg.global_variable.type</a> = type {
- uint, ;; Tag = 52 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_variable)
- { }*, ;; Global variable anchor = cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_global_variables">llvm.dbg.global_variables</a> to { }*),
- { }*, ;; Reference to context descriptor
- i8*, ;; Name
- i8*, ;; Display name (fully qualified C++ name)
- i8*, ;; MIPS linkage name (for C++)
- { }*, ;; Reference to compile unit where defined
- uint, ;; Line number where defined
- { }*, ;; Reference to type descriptor
- bool, ;; True if the global is local to compile unit (static)
- bool, ;; True if the global is defined in the compile unit (not extern)
- { }* ;; Reference to the global variable
- }
+%<a href="#format_global_variables">llvm.dbg.global_variable.type</a> = type {
+ i32, ;; Tag = 52 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_variable)
+ { }*, ;; Global variable anchor = cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_global_variables">llvm.dbg.global_variables</a> to { }*),
+ { }*, ;; Reference to context descriptor
+ i8*, ;; Name
+ i8*, ;; Display name (fully qualified C++ name)
+ i8*, ;; MIPS linkage name (for C++)
+ { }*, ;; Reference to compile unit where defined
+ i32, ;; Line number where defined
+ { }*, ;; Reference to type descriptor
+ i1, ;; True if the global is local to compile unit (static)
+ i1, ;; True if the global is defined in the compile unit (not extern)
+ { }* ;; Reference to the global variable
+}
</pre>
+</div>
<p>These descriptors provide debug information about globals variables. The
provide details such as name, type and where the variable is defined.</p>
@@ -439,27 +470,30 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_subprograms">llvm.dbg.subprogram.type</a> = type {
- uint, ;; Tag = 46 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subprogram)
- { }*, ;; Subprogram anchor = cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_subprograms">llvm.dbg.subprograms</a> to { }*),
- { }*, ;; Reference to context descriptor
- i8*, ;; Name
- i8*, ;; Display name (fully qualified C++ name)
- i8*, ;; MIPS linkage name (for C++)
- { }*, ;; Reference to compile unit where defined
- uint, ;; Line number where defined
- { }*, ;; Reference to type descriptor
- bool, ;; True if the global is local to compile unit (static)
- bool ;; True if the global is defined in the compile unit (not extern)
- }
+%<a href="#format_subprograms">llvm.dbg.subprogram.type</a> = type {
+ i32, ;; Tag = 46 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subprogram)
+ { }*, ;; Subprogram anchor = cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_subprograms">llvm.dbg.subprograms</a> to { }*),
+ { }*, ;; Reference to context descriptor
+ i8*, ;; Name
+ i8*, ;; Display name (fully qualified C++ name)
+ i8*, ;; MIPS linkage name (for C++)
+ { }*, ;; Reference to compile unit where defined
+ i32, ;; Line number where defined
+ { }*, ;; Reference to type descriptor
+ i1, ;; True if the global is local to compile unit (static)
+ i1 ;; True if the global is defined in the compile unit (not extern)
+}
</pre>
+</div>
<p>These descriptors provide debug information about functions, methods and
-subprograms. They provide details such as name, return types and the source
-location where the subprogram is defined.</p>
+ subprograms. They provide details such as name, return types and the source
+ location where the subprogram is defined.</p>
</div>
+
<!-- ======================================================================= -->
<div class="doc_subsubsection">
<a name="format_blocks">Block descriptors</a>
@@ -467,16 +501,18 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_blocks">llvm.dbg.block</a> = type {
- i32, ;; Tag = 13 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_lexical_block)
- { }* ;; Reference to context descriptor
- }
+%<a href="#format_blocks">llvm.dbg.block</a> = type {
+ i32, ;; Tag = 13 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_lexical_block)
+ { }* ;; Reference to context descriptor
+}
</pre>
+</div>
<p>These descriptors provide debug information about nested blocks within a
-subprogram. The array of member descriptors is used to define local variables
-and deeper nested blocks.</p>
+ subprogram. The array of member descriptors is used to define local
+ variables and deeper nested blocks.</p>
</div>
@@ -487,42 +523,47 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_basic_type">llvm.dbg.basictype.type</a> = type {
- uint, ;; Tag = 36 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_base_type)
- { }*, ;; Reference to context (typically a compile unit)
- i8*, ;; Name (may be "" for anonymous types)
- { }*, ;; Reference to compile unit where defined (may be NULL)
- uint, ;; Line number where defined (may be 0)
- i64, ;; Size in bits
- i64, ;; Alignment in bits
- uint, ;; Offset in bits
- uint ;; Dwarf type encoding
- }
+%<a href="#format_basic_type">llvm.dbg.basictype.type</a> = type {
+ i32, ;; Tag = 36 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_base_type)
+ { }*, ;; Reference to context (typically a compile unit)
+ i8*, ;; Name (may be "" for anonymous types)
+ { }*, ;; Reference to compile unit where defined (may be NULL)
+ i32, ;; Line number where defined (may be 0)
+ i64, ;; Size in bits
+ i64, ;; Alignment in bits
+ i64, ;; Offset in bits
+ i32, ;; Flags
+ i32 ;; DWARF type encoding
+}
</pre>
+</div>
<p>These descriptors define primitive types used in the code. Example int, bool
-and float. The context provides the scope of the type, which is usually the top
-level. Since basic types are not usually user defined the compile unit and line
-number can be left as NULL and 0. The size, alignment and offset are expressed
-in bits and can be 64 bit values. The alignment is used to round the offset
-when embedded in a <a href="#format_composite_type">composite type</a>
-(example to keep float doubles on 64 bit boundaries.) The offset is the bit
-offset if embedded in a <a href="#format_composite_type">composite
-type</a>.</p>
+ and float. The context provides the scope of the type, which is usually the
+ top level. Since basic types are not usually user defined the compile unit
+ and line number can be left as NULL and 0. The size, alignment and offset
+ are expressed in bits and can be 64 bit values. The alignment is used to
+ round the offset when embedded in a
+ <a href="#format_composite_type">composite type</a> (example to keep float
+ doubles on 64 bit boundaries.) The offset is the bit offset if embedded in
+ a <a href="#format_composite_type">composite type</a>.</p>
<p>The type encoding provides the details of the type. The values are typically
-one of the following:</p>
+ one of the following:</p>
+<div class="doc_code">
<pre>
- DW_ATE_address = 1
- DW_ATE_boolean = 2
- DW_ATE_float = 4
- DW_ATE_signed = 5
- DW_ATE_signed_char = 6
- DW_ATE_unsigned = 7
- DW_ATE_unsigned_char = 8
+DW_ATE_address = 1
+DW_ATE_boolean = 2
+DW_ATE_float = 4
+DW_ATE_signed = 5
+DW_ATE_signed_char = 6
+DW_ATE_unsigned = 7
+DW_ATE_unsigned_char = 8
</pre>
+</div>
</div>
@@ -533,60 +574,64 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> = type {
- uint, ;; Tag (see below)
- { }*, ;; Reference to context
- i8*, ;; Name (may be "" for anonymous types)
- { }*, ;; Reference to compile unit where defined (may be NULL)
- uint, ;; Line number where defined (may be 0)
- uint, ;; Size in bits
- uint, ;; Alignment in bits
- uint, ;; Offset in bits
- { }* ;; Reference to type derived from
- }
+%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> = type {
+ i32, ;; Tag (see below)
+ { }*, ;; Reference to context
+ i8*, ;; Name (may be "" for anonymous types)
+ { }*, ;; Reference to compile unit where defined (may be NULL)
+ i32, ;; Line number where defined (may be 0)
+ i32, ;; Size in bits
+ i32, ;; Alignment in bits
+ i32, ;; Offset in bits
+ { }* ;; Reference to type derived from
+}
</pre>
+</div>
<p>These descriptors are used to define types derived from other types. The
value of the tag varies depending on the meaning. The following are possible
tag values:</p>
+<div class="doc_code">
<pre>
- DW_TAG_formal_parameter = 5
- DW_TAG_member = 13
- DW_TAG_pointer_type = 15
- DW_TAG_reference_type = 16
- DW_TAG_typedef = 22
- DW_TAG_const_type = 38
- DW_TAG_volatile_type = 53
- DW_TAG_restrict_type = 55
-</pre>
-
-<p> <tt>DW_TAG_member</tt> is used to define a member of a <a
-href="#format_composite_type">composite type</a> or <a
-href="#format_subprograms">subprogram</a>. The type of the member is the <a
-href="#format_derived_type">derived type</a>. <tt>DW_TAG_formal_parameter</tt>
-is used to define a member which is a formal argument of a subprogram.</p>
-
-<p><tt>DW_TAG_typedef</tt> is used to
-provide a name for the derived type.</p>
-
-<p><tt>DW_TAG_pointer_type</tt>,
-<tt>DW_TAG_reference_type</tt>, <tt>DW_TAG_const_type</tt>,
-<tt>DW_TAG_volatile_type</tt> and <tt>DW_TAG_restrict_type</tt> are used to
-qualify the <a href="#format_derived_type">derived type</a>. </p>
+DW_TAG_formal_parameter = 5
+DW_TAG_member = 13
+DW_TAG_pointer_type = 15
+DW_TAG_reference_type = 16
+DW_TAG_typedef = 22
+DW_TAG_const_type = 38
+DW_TAG_volatile_type = 53
+DW_TAG_restrict_type = 55
+</pre>
+</div>
+
+<p><tt>DW_TAG_member</tt> is used to define a member of
+ a <a href="#format_composite_type">composite type</a>
+ or <a href="#format_subprograms">subprogram</a>. The type of the member is
+ the <a href="#format_derived_type">derived
+ type</a>. <tt>DW_TAG_formal_parameter</tt> is used to define a member which
+ is a formal argument of a subprogram.</p>
+
+<p><tt>DW_TAG_typedef</tt> is used to provide a name for the derived type.</p>
+
+<p><tt>DW_TAG_pointer_type</tt>,<tt>DW_TAG_reference_type</tt>,
+ <tt>DW_TAG_const_type</tt>, <tt>DW_TAG_volatile_type</tt>
+ and <tt>DW_TAG_restrict_type</tt> are used to qualify
+ the <a href="#format_derived_type">derived type</a>. </p>
<p><a href="#format_derived_type">Derived type</a> location can be determined
-from the compile unit and line number. The size, alignment and offset are
-expressed in bits and can be 64 bit values. The alignment is used to round the
-offset when embedded in a <a href="#format_composite_type">composite type</a>
-(example to keep float doubles on 64 bit boundaries.) The offset is the bit
-offset if embedded in a <a href="#format_composite_type">composite
-type</a>.</p>
+ from the compile unit and line number. The size, alignment and offset are
+ expressed in bits and can be 64 bit values. The alignment is used to round
+ the offset when embedded in a <a href="#format_composite_type">composite
+ type</a> (example to keep float doubles on 64 bit boundaries.) The offset is
+ the bit offset if embedded in a <a href="#format_composite_type">composite
+ type</a>.</p>
<p>Note that the <tt>void *</tt> type is expressed as a
-<tt>llvm.dbg.derivedtype.type</tt> with tag of <tt>DW_TAG_pointer_type</tt> and
-NULL derived type.</p>
+ <tt>llvm.dbg.derivedtype.type</tt> with tag of <tt>DW_TAG_pointer_type</tt>
+ and <tt>NULL</tt> derived type.</p>
</div>
@@ -597,74 +642,82 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_composite_type">llvm.dbg.compositetype.type</a> = type {
- uint, ;; Tag (see below)
- { }*, ;; Reference to context
- i8*, ;; Name (may be "" for anonymous types)
- { }*, ;; Reference to compile unit where defined (may be NULL)
- uint, ;; Line number where defined (may be 0)
- uint, ;; Size in bits
- uint, ;; Alignment in bits
- uint, ;; Offset in bits
- { }* ;; Reference to array of member descriptors
- }
+%<a href="#format_composite_type">llvm.dbg.compositetype.type</a> = type {
+ i32, ;; Tag (see below)
+ { }*, ;; Reference to context
+ i8*, ;; Name (may be "" for anonymous types)
+ { }*, ;; Reference to compile unit where defined (may be NULL)
+ i32, ;; Line number where defined (may be 0)
+ i64, ;; Size in bits
+ i64, ;; Alignment in bits
+ i64, ;; Offset in bits
+ i32, ;; Flags
+ { }*, ;; Reference to type derived from
+ { }*, ;; Reference to array of member descriptors
+ i32 ;; Runtime languages
+}
</pre>
+</div>
<p>These descriptors are used to define types that are composed of 0 or more
elements. The value of the tag varies depending on the meaning. The following
are possible tag values:</p>
+<div class="doc_code">
<pre>
- DW_TAG_array_type = 1
- DW_TAG_enumeration_type = 4
- DW_TAG_structure_type = 19
- DW_TAG_union_type = 23
- DW_TAG_vector_type = 259
- DW_TAG_subroutine_type = 46
- DW_TAG_inheritance = 26
+DW_TAG_array_type = 1
+DW_TAG_enumeration_type = 4
+DW_TAG_structure_type = 19
+DW_TAG_union_type = 23
+DW_TAG_vector_type = 259
+DW_TAG_subroutine_type = 46
+DW_TAG_inheritance = 26
</pre>
+</div>
<p>The vector flag indicates that an array type is a native packed vector.</p>
<p>The members of array types (tag = <tt>DW_TAG_array_type</tt>) or vector types
-(tag = <tt>DW_TAG_vector_type</tt>) are <a href="#format_subrange">subrange
-descriptors</a>, each representing the range of subscripts at that level of
-indexing.</p>
+ (tag = <tt>DW_TAG_vector_type</tt>) are <a href="#format_subrange">subrange
+ descriptors</a>, each representing the range of subscripts at that level of
+ indexing.</p>
<p>The members of enumeration types (tag = <tt>DW_TAG_enumeration_type</tt>) are
-<a href="#format_enumeration">enumerator descriptors</a>, each representing the
-definition of enumeration value
-for the set.</p>
+ <a href="#format_enumeration">enumerator descriptors</a>, each representing
+ the definition of enumeration value for the set.</p>
<p>The members of structure (tag = <tt>DW_TAG_structure_type</tt>) or union (tag
-= <tt>DW_TAG_union_type</tt>) types are any one of the <a
-href="#format_basic_type">basic</a>, <a href="#format_derived_type">derived</a>
-or <a href="#format_composite_type">composite</a> type descriptors, each
-representing a field member of the structure or union.</p>
+ = <tt>DW_TAG_union_type</tt>) types are any one of
+ the <a href="#format_basic_type">basic</a>,
+ <a href="#format_derived_type">derived</a>
+ or <a href="#format_composite_type">composite</a> type descriptors, each
+ representing a field member of the structure or union.</p>
<p>For C++ classes (tag = <tt>DW_TAG_structure_type</tt>), member descriptors
-provide information about base classes, static members and member functions. If
-a member is a <a href="#format_derived_type">derived type descriptor</a> and has
-a tag of <tt>DW_TAG_inheritance</tt>, then the type represents a base class. If
-the member of is a <a href="#format_global_variables">global variable
-descriptor</a> then it represents a static member. And, if the member is a <a
-href="#format_subprograms">subprogram descriptor</a> then it represents a member
-function. For static members and member functions, <tt>getName()</tt> returns
-the members link or the C++ mangled name. <tt>getDisplayName()</tt> the
-simplied version of the name.</p>
-
-<p>The first member of subroutine (tag = <tt>DW_TAG_subroutine_type</tt>)
-type elements is the return type for the subroutine. The remaining
-elements are the formal arguments to the subroutine.</p>
+ provide information about base classes, static members and member
+ functions. If a member is a <a href="#format_derived_type">derived type
+ descriptor</a> and has a tag of <tt>DW_TAG_inheritance</tt>, then the type
+ represents a base class. If the member of is
+ a <a href="#format_global_variables">global variable descriptor</a> then it
+ represents a static member. And, if the member is
+ a <a href="#format_subprograms">subprogram descriptor</a> then it represents
+ a member function. For static members and member
+ functions, <tt>getName()</tt> returns the members link or the C++ mangled
+ name. <tt>getDisplayName()</tt> the simplied version of the name.</p>
+
+<p>The first member of subroutine (tag = <tt>DW_TAG_subroutine_type</tt>) type
+ elements is the return type for the subroutine. The remaining elements are
+ the formal arguments to the subroutine.</p>
<p><a href="#format_composite_type">Composite type</a> location can be
-determined from the compile unit and line number. The size, alignment and
-offset are expressed in bits and can be 64 bit values. The alignment is used to
-round the offset when embedded in a <a href="#format_composite_type">composite
-type</a> (as an example, to keep float doubles on 64 bit boundaries.) The offset
-is the bit offset if embedded in a <a href="#format_composite_type">composite
-type</a>.</p>
+ determined from the compile unit and line number. The size, alignment and
+ offset are expressed in bits and can be 64 bit values. The alignment is used
+ to round the offset when embedded in
+ a <a href="#format_composite_type">composite type</a> (as an example, to keep
+ float doubles on 64 bit boundaries.) The offset is the bit offset if embedded
+ in a <a href="#format_composite_type">composite type</a>.</p>
</div>
@@ -675,19 +728,21 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_subrange">llvm.dbg.subrange.type</a> = type {
- uint, ;; Tag = 33 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subrange_type)
- uint, ;; Low value
- uint ;; High value
- }
+%<a href="#format_subrange">llvm.dbg.subrange.type</a> = type {
+ i32, ;; Tag = 33 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subrange_type)
+ i64, ;; Low value
+ i64 ;; High value
+}
</pre>
+</div>
<p>These descriptors are used to define ranges of array subscripts for an array
-<a href="#format_composite_type">composite type</a>. The low value defines the
-lower bounds typically zero for C/C++. The high value is the upper bounds.
-Values are 64 bit. High - low + 1 is the size of the array. If
-low == high the array will be unbounded.</p>
+ <a href="#format_composite_type">composite type</a>. The low value defines
+ the lower bounds typically zero for C/C++. The high value is the upper
+ bounds. Values are 64 bit. High - low + 1 is the size of the array. If low
+ == high the array will be unbounded.</p>
</div>
@@ -698,17 +753,19 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
- %<a href="#format_enumeration">llvm.dbg.enumerator.type</a> = type {
- uint, ;; Tag = 40 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_enumerator)
- i8*, ;; Name
- uint ;; Value
- }
+%<a href="#format_enumeration">llvm.dbg.enumerator.type</a> = type {
+ i32, ;; Tag = 40 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_enumerator)
+ i8*, ;; Name
+ i64 ;; Value
+}
</pre>
+</div>
-<p>These descriptors are used to define members of an enumeration <a
-href="#format_composite_type">composite type</a>, it associates the name to the
-value.</p>
+<p>These descriptors are used to define members of an
+ enumeration <a href="#format_composite_type">composite type</a>, it
+ associates the name to the value.</p>
</div>
@@ -718,35 +775,40 @@
</div>
<div class="doc_text">
+
+<div class="doc_code">
<pre>
- %<a href="#format_variables">llvm.dbg.variable.type</a> = type {
- uint, ;; Tag (see below)
- { }*, ;; Context
- i8*, ;; Name
- { }*, ;; Reference to compile unit where defined
- uint, ;; Line number where defined
- { }* ;; Type descriptor
- }
+%<a href="#format_variables">llvm.dbg.variable.type</a> = type {
+ i32, ;; Tag (see below)
+ { }*, ;; Context
+ i8*, ;; Name
+ { }*, ;; Reference to compile unit where defined
+ i32, ;; Line number where defined
+ { }* ;; Type descriptor
+}
</pre>
+</div>
<p>These descriptors are used to define variables local to a sub program. The
-value of the tag depends on the usage of the variable:</p>
+ value of the tag depends on the usage of the variable:</p>
+<div class="doc_code">
<pre>
- DW_TAG_auto_variable = 256
- DW_TAG_arg_variable = 257
- DW_TAG_return_variable = 258
+DW_TAG_auto_variable = 256
+DW_TAG_arg_variable = 257
+DW_TAG_return_variable = 258
</pre>
+</div>
<p>An auto variable is any variable declared in the body of the function. An
-argument variable is any variable that appears as a formal argument to the
-function. A return variable is used to track the result of a function and has
-no source correspondent.</p>
+ argument variable is any variable that appears as a formal argument to the
+ function. A return variable is used to track the result of a function and
+ has no source correspondent.</p>
<p>The context is either the subprogram or block where the variable is defined.
-Name the source variable name. Compile unit and line indicate where the
-variable was defined. Type descriptor defines the declared type of the
-variable.</p>
+ Name the source variable name. Compile unit and line indicate where the
+ variable was defined. Type descriptor defines the declared type of the
+ variable.</p>
</div>
@@ -758,7 +820,7 @@
<div class="doc_text">
<p>LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to
-provide debug information at various points in generated code.</p>
+ provide debug information at various points in generated code.</p>
</div>
@@ -773,13 +835,13 @@
</pre>
<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 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
-the next call to <tt>%<a
-href="#format_common_stoppoint">lvm.dbg.stoppoint</a></tt>.</p>
+ the generated code. The first argument is the line number (base 1), second
+ 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 the next call
+ to <tt>%<a href="#format_common_stoppoint">lvm.dbg.stoppoint</a></tt>.</p>
</div>
@@ -793,17 +855,17 @@
void %<a href="#format_common_func_start">llvm.dbg.func.start</a>( { }* )
</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
-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>
+<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 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>
</div>
@@ -818,10 +880,11 @@
</pre>
<p>This intrinsic is used to define the beginning of a declarative scope (ex.
-block) for local language elements. 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_blocks">llvm.dbg.block</a></tt> which is starting.</p>
+ block) for local language elements. 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_blocks">llvm.dbg.block</a></tt> which is
+ starting.</p>
</div>
@@ -837,13 +900,13 @@
</pre>
<p>This intrinsic is used to define the end of a declarative scope (ex. block)
-for local language elements. It should be paired off with an opening <tt>%<a
-href="#format_common_region_start">llvm.dbg.region.start</a></tt> or <tt>%<a
-href="#format_common_func_start">llvm.dbg.func.start</a></tt>. The function's
-single argument is either the <tt>%<a
-href="#format_blocks">llvm.dbg.block</a></tt> or the <tt>%<a
-href="#format_subprograms">llvm.dbg.subprogram.type</a></tt> which is
-ending.</p>
+ for local language elements. It should be paired off with an
+ opening <tt>%<a href="#format_common_region_start">llvm.dbg.region.start</a></tt>
+ or <tt>%<a href="#format_common_func_start">llvm.dbg.func.start</a></tt>.
+ The function's single argument is either
+ the <tt>%<a href="#format_blocks">llvm.dbg.block</a></tt> or
+ the <tt>%<a href="#format_subprograms">llvm.dbg.subprogram.type</a></tt>
+ which is ending.</p>
</div>
@@ -858,10 +921,10 @@
</pre>
<p>This intrinsic provides information about a local element (ex. variable.) The
-first argument is the alloca for the variable, cast to a <tt>{ }*</tt>. The
-second argument is the <tt>%<a
-href="#format_variables">llvm.dbg.variable</a></tt> containing the description
-of the variable, also cast to a <tt>{ }*</tt>.</p>
+ first argument is the alloca for the variable, cast to a <tt>{ }*</tt>. The
+ second argument is
+ the <tt>%<a href="#format_variables">llvm.dbg.variable</a></tt> containing
+ the description of the variable, also cast to a <tt>{ }*</tt>.</p>
</div>
@@ -875,30 +938,30 @@
<div class="doc_text">
<p>LLVM debugger "stop points" are a key part of the debugging representation
-that allows the LLVM to maintain simple semantics for <a
-href="#debugopt">debugging optimized code</a>. The basic idea is that the
-front-end inserts calls to the <a
-href="#format_common_stoppoint">%<tt>llvm.dbg.stoppoint</tt></a> intrinsic
-function at every point in the program where a debugger should be able to
-inspect the program (these correspond to places a debugger stops when you
-"<tt>step</tt>" through it). The front-end can choose to place these as
-fine-grained as it would like (for example, before every subexpression
-evaluated), but it is recommended to only put them after every source statement
-that includes executable code.</p>
+ that allows the LLVM to maintain simple semantics
+ for <a href="#debugopt">debugging optimized code</a>. The basic idea is that
+ the front-end inserts calls to
+ the <a href="#format_common_stoppoint">%<tt>llvm.dbg.stoppoint</tt></a>
+ intrinsic function at every point in the program where a debugger should be
+ able to inspect the program (these correspond to places a debugger stops when
+ you "<tt>step</tt>" through it). The front-end can choose to place these as
+ fine-grained as it would like (for example, before every subexpression
+ evaluated), but it is recommended to only put them after every source
+ statement that includes executable code.</p>
<p>Using calls to this intrinsic function to demark legal points for the
-debugger to inspect the program automatically disables any optimizations that
-could potentially confuse debugging information. To non-debug-information-aware
-transformations, these calls simply look like calls to an external function,
-which they must assume to do anything (including reading or writing to any part
-of reachable memory). On the other hand, it does not impact many optimizations,
-such as code motion of non-trapping instructions, nor does it impact
-optimization of subexpressions, code duplication transformations, or basic-block
-reordering transformations.</p>
+ debugger to inspect the program automatically disables any optimizations that
+ could potentially confuse debugging information. To
+ non-debug-information-aware transformations, these calls simply look like
+ calls to an external function, which they must assume to do anything
+ (including reading or writing to any part of reachable memory). On the other
+ hand, it does not impact many optimizations, such as code motion of
+ non-trapping instructions, nor does it impact optimization of subexpressions,
+ code duplication transformations, or basic-block reordering
+ transformations.</p>
</div>
-
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="format_common_lifetime">Object lifetimes and scoping</a>
@@ -906,18 +969,20 @@
<div class="doc_text">
<p>In many languages, the local variables in functions can have their lifetime
-or scope limited to a subset of a function. In the C family of languages, for
-example, variables are only live (readable and writable) within the source block
-that they are defined in. In functional languages, values are only readable
-after they have been defined. Though this is a very obvious concept, it is also
-non-trivial to model in LLVM, because it has no notion of scoping in this sense,
-and does not want to be tied to a language's scoping rules.</p>
+ or scope limited to a subset of a function. In the C family of languages,
+ for example, variables are only live (readable and writable) within the
+ source block that they are defined in. In functional languages, values are
+ only readable after they have been defined. Though this is a very obvious
+ concept, it is also non-trivial to model in LLVM, because it has no notion of
+ scoping in this sense, and does not want to be tied to a language's scoping
+ rules.</p>
<p>In order to handle this, the LLVM debug format uses the notion of "regions"
-of a function, delineated by calls to intrinsic functions. These intrinsic
-functions define new regions of the program and indicate when the region
-lifetime expires. Consider the following C fragment, for example:</p>
+ of a function, delineated by calls to intrinsic functions. These intrinsic
+ functions define new regions of the program and indicate when the region
+ lifetime expires. Consider the following C fragment, for example:</p>
+<div class="doc_code">
<pre>
1. void foo() {
2. int X = ...;
@@ -929,9 +994,11 @@
8. ...
9. }
</pre>
+</div>
<p>Compiled to LLVM, this function would be represented like this:</p>
+<div class="doc_code">
<pre>
void %foo() {
entry:
@@ -941,93 +1008,93 @@
...
- call void %<a href="#format_common_func_start">llvm.dbg.func.start</a>( %<a href="#format_subprograms">llvm.dbg.subprogram.type</a>* %llvm.dbg.subprogram )
+ call void @<a href="#format_common_func_start">llvm.dbg.func.start</a>( %<a href="#format_subprograms">llvm.dbg.subprogram.type</a>* @llvm.dbg.subprogram )
- call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 2, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+ call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 2, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* @llvm.dbg.compile_unit )
- call void %<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
- call void %<a href="#format_common_declare">llvm.dbg.declare</a>({}* %Y, ...)
+ call void @<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
+ call void @<a href="#format_common_declare">llvm.dbg.declare</a>({}* %Y, ...)
<i>;; Evaluate expression on line 2, assigning to X.</i>
- call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 3, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+ call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 3, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* @llvm.dbg.compile_unit )
<i>;; Evaluate expression on line 3, assigning to Y.</i>
- call void %<a href="#format_common_stoppoint">llvm.region.start</a>()
- call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 5, uint 4, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
- call void %<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
+ call void @<a href="#format_common_stoppoint">llvm.region.start</a>()
+ call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 5, uint 4, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* @llvm.dbg.compile_unit )
+ call void @<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
<i>;; Evaluate expression on line 5, assigning to Z.</i>
- call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 7, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
- call void %<a href="#format_common_region_end">llvm.region.end</a>()
+ call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 7, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* @llvm.dbg.compile_unit )
+ call void @<a href="#format_common_region_end">llvm.region.end</a>()
- call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 9, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+ call void @<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 9, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* @llvm.dbg.compile_unit )
- call void %<a href="#format_common_region_end">llvm.region.end</a>()
+ call void @<a href="#format_common_region_end">llvm.region.end</a>()
ret void
}
</pre>
+</div>
<p>This example illustrates a few important details about the LLVM debugging
-information. In particular, it shows how the various intrinsics are applied
-together to allow a debugger to analyze the relationship between statements,
-variable definitions, and the code used to implement the function.</p>
-
-<p>The first intrinsic <tt>%<a
-href="#format_common_func_start">llvm.dbg.func.start</a></tt> provides
-a link with the <a href="#format_subprograms">subprogram descriptor</a>
-containing the details of this function. This call also defines the beginning
-of the function region, bounded by the <tt>%<a
-href="#format_common_region_end">llvm.region.end</a></tt> at the end of
-the function. This region is used to bracket the lifetime of variables declared
-within. For a function, this outer region defines a new stack frame whose
-lifetime ends when the region is ended.</p>
+ information. In particular, it shows how the various intrinsics are applied
+ together to allow a debugger to analyze the relationship between statements,
+ variable definitions, and the code used to implement the function.</p>
+
+<p>The first
+ intrinsic <tt>%<a href="#format_common_func_start">llvm.dbg.func.start</a></tt>
+ provides a link with the <a href="#format_subprograms">subprogram
+ descriptor</a> containing the details of this function. This call also
+ defines the beginning of the function region, bounded by
+ the <tt>%<a href="#format_common_region_end">llvm.region.end</a></tt> at the
+ end of the function. This region is used to bracket the lifetime of
+ variables declared within. For a function, this outer region defines a new
+ stack frame whose lifetime ends when the region is ended.</p>
<p>It is possible to define inner regions for short term variables by using the
-%<a href="#format_common_stoppoint"><tt>llvm.region.start</tt></a> and <a
-href="#format_common_region_end"><tt>%llvm.region.end</tt></a> to bound a
-region. The inner region in this example would be for the block containing the
-declaration of Z.</p>
+ %<a href="#format_common_stoppoint"><tt>llvm.region.start</tt></a>
+ and <a href="#format_common_region_end"><tt>%llvm.region.end</tt></a> to
+ bound a region. The inner region in this example would be for the block
+ containing the declaration of Z.</p>
<p>Using regions to represent the boundaries of source-level functions allow
-LLVM interprocedural optimizations to arbitrarily modify LLVM functions without
-having to worry about breaking mapping information between the LLVM code and the
-and source-level program. In particular, the inliner requires no modification
-to support inlining with debugging information: there is no explicit correlation
-drawn between LLVM functions and their source-level counterparts (note however,
-that if the inliner inlines all instances of a non-strong-linkage function into
-its caller that it will not be possible for the user to manually invoke the
-inlined function from a debugger).</p>
-
-<p>Once the function has been defined, the <a
-href="#format_common_stoppoint"><tt>stopping point</tt></a> corresponding to
-line #2 (column #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 introduced into the program using
-%<a href="#format_common_declare"><tt>llvm.dbg.declare</tt></a>, 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>
+ LLVM interprocedural optimizations to arbitrarily modify LLVM functions
+ without having to worry about breaking mapping information between the LLVM
+ code and the and source-level program. In particular, the inliner requires
+ no modification to support inlining with debugging information: there is no
+ explicit correlation drawn between LLVM functions and their source-level
+ counterparts (note however, that if the inliner inlines all instances of a
+ non-strong-linkage function into its caller that it will not be possible for
+ the user to manually invoke the inlined function from a debugger).</p>
+
+<p>Once the function has been defined,
+ the <a href="#format_common_stoppoint"><tt>stopping point</tt></a>
+ corresponding to line #2 (column #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 introduced into
+ the program using
+ %<a href="#format_common_declare"><tt>llvm.dbg.declare</tt></a>, 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 the inner region, which kills
-the availability of <tt>Z</tt> before the code for line 8 is executed. In this
-way, regions can support arbitrary source-language scoping rules, as long as
-they can only be nested (ie, one scope cannot partially overlap with a part of
-another scope).</p>
+ on line 7. For this reason, it is defined within the inner region, which
+ kills the availability of <tt>Z</tt> before the code for line 8 is executed.
+ In this way, regions can support arbitrary source-language scoping rules, 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 could change how name lookup is
-performed.</p>
+ all declarations, not just variable declarations. For example, the scope of
+ a C++ using declaration is controlled with this and could change how name
+ lookup is performed.</p>
</div>
-
-
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="ccxx_frontend">C/C++ front-end specific debug information</a>
@@ -1037,21 +1104,23 @@
<div class="doc_text">
<p>The C and C++ front-ends represent information about the program in a format
-that is effectively identical to <a
-href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3.0</a> in terms of
-information content. This allows code generators to trivially support native
-debuggers by generating standard dwarf information, and contains enough
-information for non-dwarf targets to translate it as needed.</p>
+ that is effectively identical
+ to <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3.0</a> in
+ terms of information content. This allows code generators to trivially
+ support native debuggers by generating standard dwarf information, and
+ contains enough information for non-dwarf targets to translate it as
+ needed.</p>
<p>This section describes the forms used to represent C and C++ programs. Other
-languages could pattern themselves after this (which itself is tuned to
-representing programs in the same way that Dwarf 3 does), or they could choose
-to provide completely different forms if they don't fit into the Dwarf model.
-As support for debugging information gets added to the various LLVM
-source-language front-ends, the information used should be documented here.</p>
+ languages could pattern themselves after this (which itself is tuned to
+ representing programs in the same way that DWARF 3 does), or they could
+ choose to provide completely different forms if they don't fit into the DWARF
+ model. As support for debugging information gets added to the various LLVM
+ source-language front-ends, the information used should be documented
+ here.</p>
<p>The following sections provide examples of various C/C++ constructs and the
-debug information that would best describe those constructs.</p>
+ debug information that would best describe those constructs.</p>
</div>
@@ -1062,9 +1131,10 @@
<div class="doc_text">
-<p>Given the source files "MySource.cpp" and "MyHeader.h" located in the
-directory "/Users/mine/sources", the following code:</p>
+<p>Given the source files <tt>MySource.cpp</tt> and <tt>MyHeader.h</tt> located
+ in the directory <tt>/Users/mine/sources</tt>, the following code:</p>
+<div class="doc_code">
<pre>
#include "MyHeader.h"
@@ -1072,9 +1142,11 @@
return 0;
}
</pre>
+</div>
<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="doc_code">
<pre>
...
;;
@@ -1124,6 +1196,7 @@
%str4 = internal constant [11 x i8] c"MyHeader.h\00", section "llvm.metadata";
...
</pre>
+</div>
</div>
@@ -1136,12 +1209,15 @@
<p>Given an integer global variable declared as follows:</p>
+<div class="doc_code">
<pre>
int MyGlobal = 100;
</pre>
+</div>
<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="doc_code">
<pre>
;;
;; Define types used. One for global variable anchors, one for the global
@@ -1204,6 +1280,7 @@
%str2 = internal constant [1 x i8] c"\00", section "llvm.metadata"
%str3 = internal constant [4 x i8] c"int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1216,14 +1293,17 @@
<p>Given a function declared as follows:</p>
+<div class="doc_code">
<pre>
int main(int argc, char *argv[]) {
return 0;
}
</pre>
+</div>
<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="doc_code">
<pre>
;;
;; Define types used. One for subprogram anchors, one for the subprogram
@@ -1269,6 +1349,7 @@
...
}
</pre>
+</div>
</div>
@@ -1290,6 +1371,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1303,6 +1385,7 @@
uint 2 }, section "llvm.metadata"
%str1 = internal constant [5 x i8] c"bool\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1313,6 +1396,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1326,6 +1410,7 @@
uint 6 }, section "llvm.metadata"
%str1 = internal constant [5 x i8] c"char\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1336,6 +1421,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1349,6 +1435,7 @@
uint 8 }, section "llvm.metadata"
%str1 = internal constant [14 x i8] c"unsigned char\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1359,6 +1446,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1372,6 +1460,7 @@
uint 5 }, section "llvm.metadata"
%str1 = internal constant [10 x i8] c"short int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1382,6 +1471,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1395,6 +1485,7 @@
uint 7 }, section "llvm.metadata"
%str1 = internal constant [19 x i8] c"short unsigned int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1405,6 +1496,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1417,7 +1509,7 @@
uint 0,
uint 5 }, section "llvm.metadata"
%str1 = internal constant [4 x i8] c"int\00", section "llvm.metadata"
-</pre>
+</pre></div>
</div>
@@ -1428,6 +1520,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1441,6 +1534,7 @@
uint 7 }, section "llvm.metadata"
%str1 = internal constant [13 x i8] c"unsigned int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1451,6 +1545,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1464,6 +1559,7 @@
uint 5 }, section "llvm.metadata"
%str1 = internal constant [14 x i8] c"long long int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1474,6 +1570,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1487,6 +1584,7 @@
uint 7 }, section "llvm.metadata"
%str1 = internal constant [23 x 8] c"long long unsigned int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1497,6 +1595,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1510,6 +1609,7 @@
uint 4 }, section "llvm.metadata"
%str1 = internal constant [6 x i8] c"float\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1520,6 +1620,7 @@
<div class="doc_text">
+<div class="doc_code">
<pre>
%<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
uint add(uint 36, uint 262144),
@@ -1533,6 +1634,7 @@
uint 4 }, section "llvm.metadata"
%str1 = internal constant [7 x 8] c"double\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1545,12 +1647,15 @@
<p>Given the following as an example of C/C++ derived type:</p>
+<div class="doc_code">
<pre>
typedef const int *IntPtr;
</pre>
+</div>
<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="doc_code">
<pre>
;;
;; Define the typedef "IntPtr".
@@ -1610,6 +1715,7 @@
uint 5 }, section "llvm.metadata"
%str2 = internal constant [4 x 8] c"int\00", section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1622,6 +1728,7 @@
<p>Given the following as an example of C/C++ struct type:</p>
+<div class="doc_code">
<pre>
struct Color {
unsigned Red;
@@ -1629,9 +1736,11 @@
unsigned Blue;
};
</pre>
+</div>
<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="doc_code">
<pre>
;;
;; Define basic type for unsigned int.
@@ -1717,6 +1826,7 @@
{ }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype2</a> to { }*),
{ }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype3</a> to { }*) ], section "llvm.metadata"
</pre>
+</div>
</div>
@@ -1729,6 +1839,7 @@
<p>Given the following as an example of C/C++ enumeration type:</p>
+<div class="doc_code">
<pre>
enum Trees {
Spruce = 100,
@@ -1736,9 +1847,11 @@
Maple = 300
};
</pre>
+</div>
<p>a C/C++ front-end would generate the following descriptors:</p>
+<div class="doc_code">
<pre>
;;
;; Define composite type for enum Trees
@@ -1791,6 +1904,7 @@
{ }* cast (%<a href="#format_enumeration">llvm.dbg.enumerator.type</a>* %<a href="#format_enumeration">llvm.dbg.enumerator2</a> to { }*),
{ }* cast (%<a href="#format_enumeration">llvm.dbg.enumerator.type</a>* %<a href="#format_enumeration">llvm.dbg.enumerator3</a> to { }*) ], section "llvm.metadata"
</pre>
+</div>
</div>
More information about the llvm-commits
mailing list