X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FSourceLevelDebugging.html;h=0b6ed477e049b0f79eed3e97dc9c4d5568b55051;hb=b6c29d55123f6b8c3f9e4d56e4be653a1fd2a472;hp=447a659dec03cc362b4562b664f7c5681d2c68bb;hpb=2d395d9f656366f0f7c41c397a56bfcc3f24675a;p=oota-llvm.git diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html index 447a659dec0..0b6ed477e04 100644 --- a/docs/SourceLevelDebugging.html +++ b/docs/SourceLevelDebugging.html @@ -2,6 +2,7 @@ "http://www.w3.org/TR/html4/strict.dtd"> + Source Level Debugging with LLVM @@ -66,7 +67,7 @@ height="369">

Written by Chris Lattner - and Jim Laskey

+ and Jim Laskey

@@ -77,10 +78,11 @@ height="369">

This document is the central repository for all information pertaining to -debug information in LLVM. It describes the actual format -that the LLVM debug information 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++.

+ debug information in LLVM. It describes the actual format + that the LLVM debug information 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++.

@@ -92,45 +94,45 @@ document provides specifc examples of what debug information for C/C++.

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:

+ 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:

-

The approach used by the LLVM implementation is to use a small set of intrinsic functions 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 implementation-defined format (the C/C++ front-end -currently uses working draft 7 of the Dwarf 3 standard).

+

The approach used by the LLVM implementation is to use a small set + of intrinsic functions 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 implementation-defined format + (the C/C++ front-end currently uses working draft 7 of + the DWARF 3 + standard).

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.

+ 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.

@@ -140,18 +142,19 @@ a specific language of family of languages.

+

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.

+ stripped away during the compilation process. This meta information provides + an LLVM user a relationship between generated code and the original program + source code.

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.

+ information used by the gdb debugger. Other targets could use the same + information to produce stabs or other debug forms.

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.

+ for analysis of generated code, or, tools for reconstructing the original + source from generated code.

TODO - expound a bit more.

@@ -165,48 +168,65 @@ from generated code.

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:

+ interact well with optimizations and analysis. In particular, the LLVM debug + information provides the following guarantees:

Basically, the debug information allows you to compile a program with -"-O0 -g" and get full debug information, allowing you to arbitrarily -modify the program as it executes from a debugger. Compiling a program with -"-O3 -g" 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.

+ "-O0 -g" and get full debug information, allowing you to arbitrarily + modify the program as it executes from a debugger. Compiling a program with + "-O3 -g" 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.

+ +

LLVM test suite provides a + framework to test optimizer's handling of debugging information. It can be + run like this:

+ +
+
+% cd llvm/projects/test-suite/MultiSource/Benchmarks  # or some other level
+% make TEST=dbgopt
+
+
+ +

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 TestingGuide for more + information on LLVM test infrastructure and how to run various tests.

@@ -219,44 +239,45 @@ completely.

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 -linkonce functions.

+ 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 linkonce functions.

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 --globaldce pass), the extraneous debug information will automatically -become dead and be removed by the optimizer.

+ 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 + -globaldce pass), the extraneous debug information will + automatically become dead and be removed by the optimizer.

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 "llvm.metadata" -section. All values declared in this section are stripped away after target -debug information is constructed and before the program object is emitted.

+ 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 "llvm.metadata" section. All values declared in this section + are stripped away after target debug information is constructed and before + the program object is emitted.

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 source files, and program objects. These abstract objects are -used by a debugger to form stack traces, show information about local -variables, etc.

+ 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 source files, + and program objects. These abstract + objects are used by a debugger to form stack traces, show information about + local variables, etc.

This section of the documentation first describes the representation aspects -common to any source-language. The next section -describes the data layout conventions used by the C and C++ front-ends.

+ common to any source-language. The next section + describes the data layout conventions used by the C and C++ front-ends.

@@ -266,42 +287,50 @@ describes the data layout conventions used by the C and C++ front-ends.

+

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.

+ 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.

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.)

- -

The fields of debug descriptors used internally by LLVM (MachineDebugInfo) -are restricted to only the simple data types int, uint, -bool, float, double, sbyte* and { }* -. References to arbitrary values are handled using a { }* and a -cast to { }* expression; typically references to other field -descriptors, arrays of descriptors or global variables.

- + 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.)

+ +

The fields of debug descriptors used internally by LLVM (MachineModuleInfo) + are restricted to only the simple data types int, uint, + bool, float, double, i8* and + { }*. References to arbitrary values are handled using a + { }* and a cast to { }* expression; typically + references to other field descriptors, arrays of descriptors or global + variables.

+ +
-  %llvm.dbg.object.type = type {
-    uint,   ;; A tag
-    ...
-  }
+%llvm.dbg.object.type = type {
+  uint,   ;; A tag
+  ...
+}
+
-

The first field of a descriptor is always an uint 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.

+

The first field of a descriptor is always an + uint 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.)

-

The details of the various descriptors follow.

+

The details of the various descriptors follow.

@@ -312,34 +341,48 @@ the information supplied to Dwarf targets.

+
-  %llvm.dbg.anchor.type = type {
-    uint,   ;; Tag = 0
-    uint    ;; Tag of descriptors grouped by the anchor
-  }
+%llvm.dbg.anchor.type = type {
+  i32,   ;; Tag = 0 + LLVMDebugVersion
+  i32    ;; Tag of descriptors grouped by the anchor
+}
+

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.

+ LLVM debugger to efficiently index all of the global objects without having + to 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.

The following names are recognized as anchors by LLVM:

+
-  %llvm.dbg.compile_units       = linkonce constant %llvm.dbg.anchor.type  { uint 0, uint 17 } ;; DW_TAG_compile_unit
-  %llvm.dbg.global_variables    = linkonce constant %llvm.dbg.anchor.type  { uint 0, uint 52 } ;; DW_TAG_variable
-  %llvm.dbg.subprograms         = linkonce constant %llvm.dbg.anchor.type  { uint 0, uint 46 } ;; DW_TAG_subprogram
+%llvm.dbg.compile_units = linkonce constant %llvm.dbg.anchor.type {
+  i32 0,
+  i32 17
+} ;; DW_TAG_compile_unit
+%llvm.dbg.global_variables = linkonce constant %llvm.dbg.anchor.type {
+  i32 0,
+  i32 52
+} ;; DW_TAG_variable
+%llvm.dbg.subprograms = linkonce constant %llvm.dbg.anchor.type {
+  i32 0,
+  i32 46
+} ;; DW_TAG_subprogram
+

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.

+ 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.

@@ -350,28 +393,42 @@ deleted.

+
-  %llvm.dbg.compile_unit.type = type {
-    uint,   ;; Tag = 17 (DW_TAG_compile_unit)
-    {  }*,  ;; Compile unit anchor = cast = (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to {  }*)
-    uint,   ;; LLVM debug version number = 3
-    uint,   ;; Dwarf language identifier (ex. DW_LANG_C89) 
-    sbyte*, ;; Source file name
-    sbyte*, ;; Source file directory (includes trailing slash)
-    sbyte*  ;; Producer (ex. "4.0.1 LLVM (LLVM research group)")
-  }
+%llvm.dbg.compile_unit.type = type {
+  i32,    ;; Tag = 17 + LLVMDebugVersion (DW_TAG_compile_unit)
+  {  }*,  ;; Compile unit anchor = cast = (%llvm.dbg.anchor.type* %llvm.dbg.compile_units 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
+}
+
+ +

These descriptors contain a source language ID for the file (we use the DWARF + 3.0 ID numbers, such as DW_LANG_C89, DW_LANG_C_plus_plus, + DW_LANG_Cobol74, etc), three strings describing the filename, + working directory of the compiler, and an identifier string for the compiler + that produced it.

-

These descriptors contain the version number for the debug info (currently -3), a source language ID for the file (we use the Dwarf 3.0 ID numbers, such as -DW_LANG_C89, DW_LANG_C_plus_plus, DW_LANG_Cobol74, -etc), three strings describing the filename, working directory of the compiler, -and an identifier string for the compiler that produced it.

+

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.

-

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.

+

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.

@@ -382,20 +439,24 @@ line correspondence.

+
-  %llvm.dbg.global_variable.type = type {
-    uint,   ;; Tag = 52 (DW_TAG_variable)
-    {  }*,  ;; Global variable anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables to {  }*),  
-    {  }*,  ;; Reference to context descriptor
-    sbyte*, ;; Name
-    {  }*,  ;; 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
-  }
+%llvm.dbg.global_variable.type = type {
+  i32,    ;; Tag = 52 + LLVMDebugVersion (DW_TAG_variable)
+  {  }*,  ;; Global variable anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables 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
+}
+

These descriptors provide debug information about globals variables. The provide details such as name, type and where the variable is defined.

@@ -409,25 +470,30 @@ provide details such as name, type and where the variable is defined.

+
-  %llvm.dbg.subprogram.type = type {
-    uint,   ;; Tag = 46 (DW_TAG_subprogram)
-    {  }*,  ;; Subprogram anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms to {  }*),  
-    {  }*,  ;; Reference to context descriptor
-    sbyte*, ;; Name
-    {  }*,  ;; 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)
-  }
+%llvm.dbg.subprogram.type = type {
+  i32,    ;; Tag = 46 + LLVMDebugVersion (DW_TAG_subprogram)
+  {  }*,  ;; Subprogram anchor = cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms 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)
+}
+

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.

+ subprograms. They provide details such as name, return types and the source + location where the subprogram is defined.

+
Block descriptors @@ -435,16 +501,18 @@ location where the subprogram is defined.

+
-  %llvm.dbg.block = type {
-    uint,   ;; Tag = 13 (DW_TAG_lexical_block)
-    {  }*   ;; Reference to context descriptor
-  }
+%llvm.dbg.block = type {
+  i32,    ;; Tag = 13 + LLVMDebugVersion (DW_TAG_lexical_block)
+  {  }*   ;; Reference to context descriptor
+}
+

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.

+ subprogram. The array of member descriptors is used to define local + variables and deeper nested blocks.

@@ -455,42 +523,47 @@ and deeper nested blocks.

+
-  %llvm.dbg.basictype.type = type {
-    uint,   ;; Tag = 36 (DW_TAG_base_type)
-    {  }*,  ;; Reference to context (typically a compile unit)
-    sbyte*, ;; 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
-    uint    ;; Dwarf type encoding
-  }
+%llvm.dbg.basictype.type = type {
+  i32,    ;; Tag = 36 + LLVMDebugVersion (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
+}
+

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 composite type -(example to keep float doubles on 64 bit boundaries.) The offset is the bit -offset if embedded in a composite -type.

+ 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 + composite type (example to keep float + doubles on 64 bit boundaries.) The offset is the bit offset if embedded in + a composite type.

The type encoding provides the details of the type. The values are typically -one of the following;

+ one of the following:

+
-  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
+
@@ -501,60 +574,64 @@ one of the following;

+
-  %llvm.dbg.derivedtype.type = type {
-    uint,   ;; Tag (see below)
-    {  }*,  ;; Reference to context
-    sbyte*, ;; 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
-  }
+%llvm.dbg.derivedtype.type = 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
+}
+

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;

+tag values:

+
-  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
+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
+
-

DW_TAG_member is used to define a member of a composite type or subprogram. The type of the member is the derived type. DW_TAG_formal_parameter -is used to define a member which is a formal argument of a subprogram.

+

DW_TAG_member is used to define a member of + a composite type + or subprogram. The type of the member is + the derived + type. DW_TAG_formal_parameter is used to define a member which + is a formal argument of a subprogram.

-

DW_TAG_typedef is used to -provide a name for the derived type.

+

DW_TAG_typedef is used to provide a name for the derived type.

-

DW_TAG_pointer_type, -DW_TAG_reference_type, DW_TAG_const_type, -DW_TAG_volatile_type and DW_TAG_restrict_type are used to -qualify the derived type.

+

DW_TAG_pointer_type,DW_TAG_reference_type, + DW_TAG_const_type, DW_TAG_volatile_type + and DW_TAG_restrict_type are used to qualify + the derived type.

Derived type 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 composite type -(example to keep float doubles on 64 bit boundaries.) The offset is the bit -offset if embedded in a composite -type.

+ 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 composite + type (example to keep float doubles on 64 bit boundaries.) The offset is + the bit offset if embedded in a composite + type.

Note that the void * type is expressed as a -llvm.dbg.derivedtype.type with tag of DW_TAG_pointer_type and -NULL derived type.

+ llvm.dbg.derivedtype.type with tag of DW_TAG_pointer_type + and NULL derived type.

@@ -565,53 +642,82 @@ NULL derived type.

+
-  %llvm.dbg.compositetype.type = type {
-    uint,   ;; Tag (see below)
-    {  }*,  ;; Reference to context
-    sbyte*, ;; 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
-  }
+%llvm.dbg.compositetype.type = 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
+}
+

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;

+are possible tag values:

+
-  DW_TAG_array_type = 1
-  DW_TAG_enumeration_type = 4
-  DW_TAG_structure_type = 19
-  DW_TAG_union_type = 23
+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  = 21
+DW_TAG_inheritance      = 28
+
-

The members of array types (tag = DW_TAG_array_type) are subrange descriptors, each representing the range of -subscripts at that level of indexing.

+

The vector flag indicates that an array type is a native packed vector.

+ +

The members of array types (tag = DW_TAG_array_type) or vector types + (tag = DW_TAG_vector_type) are subrange + descriptors, each representing the range of subscripts at that level of + indexing.

The members of enumeration types (tag = DW_TAG_enumeration_type) are -enumerator descriptors, each representing the -definition of enumeration value -for the set.

+ enumerator descriptors, each representing + the definition of enumeration value for the set.

The members of structure (tag = DW_TAG_structure_type) or union (tag -= DW_TAG_union_type) types are any one of the basic, derived -or composite type descriptors, each -representing a field member of the structure or union.

+ = DW_TAG_union_type) types are any one of + the basic, + derived + or composite type descriptors, each + representing a field member of the structure or union.

+ +

For C++ classes (tag = DW_TAG_structure_type), member descriptors + provide information about base classes, static members and member + functions. If a member is a derived type + descriptor and has a tag of DW_TAG_inheritance, then the type + represents a base class. If the member of is + a global variable descriptor then it + represents a static member. And, if the member is + a subprogram descriptor then it represents + a member function. For static members and member + functions, getName() returns the members link or the C++ mangled + name. getDisplayName() the simplied version of the name.

+ +

The first member of subroutine (tag = DW_TAG_subroutine_type) type + elements is the return type for the subroutine. The remaining elements are + the formal arguments to the subroutine.

Composite type 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 composite -type (as an example, to keep float doubles on 64 bit boundaries.) The offset -is the bit offset if embedded in a composite -type.

+ 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 composite type (as an example, to keep + float doubles on 64 bit boundaries.) The offset is the bit offset if embedded + in a composite type.

@@ -622,19 +728,21 @@ type.

+
-  %llvm.dbg.subrange.type = type {
-    uint,   ;; Tag = 33 (DW_TAG_subrange_type)
-    uint,   ;; Low value
-    uint    ;; High value
-  }
+%llvm.dbg.subrange.type = type {
+  i32,    ;; Tag = 33 + LLVMDebugVersion (DW_TAG_subrange_type)
+  i64,    ;; Low value
+  i64     ;; High value
+}
+

These descriptors are used to define ranges of array subscripts for an array -composite type. 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.

+ composite type. 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.

@@ -645,17 +753,19 @@ low == high the array will be unbounded.

+
-  %llvm.dbg.enumerator.type = type {
-    uint,   ;; Tag = 40 (DW_TAG_enumerator)
-    sbyte*, ;; Name
-    uint    ;; Value
-  }
+%llvm.dbg.enumerator.type = type {
+  i32,    ;; Tag = 40 + LLVMDebugVersion (DW_TAG_enumerator)
+  i8*,    ;; Name
+  i64     ;; Value
+}
+
-

These descriptors are used to define members of an enumeration composite type, it associates the name to the -value.

+

These descriptors are used to define members of an + enumeration composite type, it + associates the name to the value.

@@ -665,35 +775,40 @@ value.

+ +
-  %llvm.dbg.variable.type = type {
-    uint,    ;; Tag (see below)
-    {  }*,   ;; Context
-    sbyte*,  ;; Name
-    {  }*,   ;; Reference to compile unit where defined
-    uint,    ;; Line number where defined
-    {  }*    ;; Type descriptor
-  }
+%llvm.dbg.variable.type = type {
+  i32,     ;; Tag (see below)
+  {  }*,   ;; Context
+  i8*,     ;; Name
+  {  }*,   ;; Reference to compile unit where defined
+  i32,     ;; Line number where defined
+  {  }*    ;; Type descriptor
+}
+

These descriptors are used to define variables local to a sub program. The -value of the tag depends on the usage of the variable;

+ value of the tag depends on the usage of the variable:

+
-  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
+

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.

+ 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.

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.

+ Name the source variable name. Compile unit and line indicate where the + variable was defined. Type descriptor defines the declared type of the + variable.

@@ -705,7 +820,7 @@ variable.

LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to -provide debug information at various points in generated code.

+ provide debug information at various points in generated code.

@@ -720,13 +835,13 @@ provide debug information at various points in generated code.

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 -%llvm.dbg.compile_unit* cast to a -{ }*. 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 %lvm.dbg.stoppoint.

+ 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 %llvm.dbg.compile_unit* + cast to a { }*. 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 %lvm.dbg.stoppoint.

@@ -740,14 +855,17 @@ href="#format_common_stoppoint">lvm.dbg.stoppoint.

void %llvm.dbg.func.start( { }* ) -

This intrinsic is used to link the debug information in %llvm.dbg.subprogram 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 %llvm.dbg.region.end. The function's -single argument is the %llvm.dbg.subprogram.type.

+

This intrinsic is used to link the debug information + in %llvm.dbg.subprogram to the + function. It defines the beginning of the function's declarative region + (scope). It also implies a call to + %llvm.dbg.stoppoint 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 + %llvm.dbg.region.end. + The function's single argument is + the %llvm.dbg.subprogram.type.

@@ -762,10 +880,11 @@ href="#format_subprograms">llvm.dbg.subprogram.type.

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 -%llvm.dbg.region.end. The -function's single argument is the %llvm.dbg.block which is starting.

+ block) for local language elements. It should be paired off with a closing + %llvm.dbg.region.end. The + function's single argument is + the %llvm.dbg.block which is + starting.

@@ -781,13 +900,13 @@ href="#format_blocks">llvm.dbg.block which is starting.

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 %llvm.dbg.region.start or %llvm.dbg.func.start. The function's -single argument is either the %llvm.dbg.block or the %llvm.dbg.subprogram.type which is -ending.

+ for local language elements. It should be paired off with an + opening %llvm.dbg.region.start + or %llvm.dbg.func.start. + The function's single argument is either + the %llvm.dbg.block or + the %llvm.dbg.subprogram.type + which is ending.

@@ -802,10 +921,10 @@ ending.

This intrinsic provides information about a local element (ex. variable.) The -first argument is the alloca for the variable, cast to a { }*. The -second argument is the %llvm.dbg.variable containing the description -of the variable, also cast to a { }*.

+ first argument is the alloca for the variable, cast to a { }*. The + second argument is + the %llvm.dbg.variable containing + the description of the variable, also cast to a { }*.

@@ -819,30 +938,30 @@ of the variable, also cast to a { }*.

LLVM debugger "stop points" are a key part of the debugging representation -that allows the LLVM to maintain simple semantics for debugging optimized code. The basic idea is that the -front-end inserts calls to the %llvm.dbg.stoppoint 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 -"step" 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.

+ that allows the LLVM to maintain simple semantics + for debugging optimized code. The basic idea is that + the front-end inserts calls to + the %llvm.dbg.stoppoint + 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 "step" 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.

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.

+ 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.

-
Object lifetimes and scoping @@ -850,18 +969,20 @@ reordering transformations.

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.

+ 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.

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:

+ 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:

+
 1.  void foo() {
 2.    int X = ...;
@@ -873,9 +994,11 @@ lifetime expires.  Consider the following C fragment, for example:

 8.    ...
 9.  }
+

Compiled to LLVM, this function would be represented like this:

+
 void %foo() {
 entry:
@@ -885,93 +1008,93 @@ entry:
     
     ...
     
-    call void %llvm.dbg.func.start( %llvm.dbg.subprogram.type* %llvm.dbg.subprogram )
+    call void @llvm.dbg.func.start( %llvm.dbg.subprogram.type* @llvm.dbg.subprogram )
     
-    call void %llvm.dbg.stoppoint( uint 2, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
+    call void @llvm.dbg.stoppoint( uint 2, uint 2, %llvm.dbg.compile_unit* @llvm.dbg.compile_unit )
     
-    call void %llvm.dbg.declare({}* %X, ...)
-    call void %llvm.dbg.declare({}* %Y, ...)
+    call void @llvm.dbg.declare({}* %X, ...)
+    call void @llvm.dbg.declare({}* %Y, ...)
     
     ;; Evaluate expression on line 2, assigning to X.
     
-    call void %llvm.dbg.stoppoint( uint 3, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
+    call void @llvm.dbg.stoppoint( uint 3, uint 2, %llvm.dbg.compile_unit* @llvm.dbg.compile_unit )
     
     ;; Evaluate expression on line 3, assigning to Y.
     
-    call void %llvm.region.start()
-    call void %llvm.dbg.stoppoint( uint 5, uint 4, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
-    call void %llvm.dbg.declare({}* %X, ...)
+    call void @llvm.region.start()
+    call void @llvm.dbg.stoppoint( uint 5, uint 4, %llvm.dbg.compile_unit* @llvm.dbg.compile_unit )
+    call void @llvm.dbg.declare({}* %X, ...)
     
     ;; Evaluate expression on line 5, assigning to Z.
     
-    call void %llvm.dbg.stoppoint( uint 7, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
-    call void %llvm.region.end()
+    call void @llvm.dbg.stoppoint( uint 7, uint 2, %llvm.dbg.compile_unit* @llvm.dbg.compile_unit )
+    call void @llvm.region.end()
     
-    call void %llvm.dbg.stoppoint( uint 9, uint 2, %llvm.dbg.compile_unit* %llvm.dbg.compile_unit )
+    call void @llvm.dbg.stoppoint( uint 9, uint 2, %llvm.dbg.compile_unit* @llvm.dbg.compile_unit )
     
-    call void %llvm.region.end()
+    call void @llvm.region.end()
     
     ret void
 }
+

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.

- -

The first intrinsic %llvm.dbg.func.start provides -a link with the subprogram descriptor -containing the details of this function. This call also defines the beginning -of the function region, bounded by the %llvm.region.end 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.

+ 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.

+ +

The first + intrinsic %llvm.dbg.func.start + provides a link with the subprogram + descriptor containing the details of this function. This call also + defines the beginning of the function region, bounded by + the %llvm.region.end 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.

It is possible to define inner regions for short term variables by using the -%llvm.region.start and %llvm.region.end to bound a -region. The inner region in this example would be for the block containing the -declaration of Z.

+ %llvm.region.start + and %llvm.region.end to + bound a region. The inner region in this example would be for the block + containing the declaration of Z.

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).

- -

Once the function has been defined, the stopping point corresponding to -line #2 (column #2) of the function is encountered. At this point in the -function, no local variables are live. As lines 2 and 3 of the example -are executed, their variable definitions are introduced into the program using -%llvm.dbg.declare, 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.

+ 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).

+ +

Once the function has been defined, + the stopping point + corresponding to line #2 (column #2) of the function is encountered. At this + point in the function, no local variables are live. As lines 2 and 3 + of the example are executed, their variable definitions are introduced into + the program using + %llvm.dbg.declare, 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.

In contrast, the Z 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 Z 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).

+ on line 7. For this reason, it is defined within the inner region, which + kills the availability of Z 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).

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 -performed.

+ 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.

- -
C/C++ front-end specific debug information @@ -981,21 +1104,23 @@ performed.

The C and C++ front-ends represent information about the program in a format -that is effectively identical to Dwarf 3.0 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.

+ that is effectively identical + to DWARF 3.0 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.

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.

+ 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.

The following sections provide examples of various C/C++ constructs and the -debug information that would best describe those constructs.

+ debug information that would best describe those constructs.

@@ -1006,9 +1131,10 @@ debug information that would best describe those constructs.

-

Given the source files "MySource.cpp" and "MyHeader.h" located in the -directory "/Users/mine/sources", the following code;

+

Given the source files MySource.cpp and MyHeader.h located + in the directory /Users/mine/sources, the following code:

+
 #include "MyHeader.h"
 
@@ -1016,9 +1142,11 @@ int main(int argc, char *argv[]) {
   return 0;
 }
+
-

a C/C++ front-end would generate the following descriptors;

+

a C/C++ front-end would generate the following descriptors:

+
 ...
 ;;
@@ -1026,7 +1154,7 @@ int main(int argc, char *argv[]) {
 ;; for compile units.
 ;;
 %llvm.dbg.anchor.type = type { uint, uint }
-%llvm.dbg.compile_unit.type = type { uint, {  }*, uint, uint, sbyte*, sbyte*, sbyte* }
+%llvm.dbg.compile_unit.type = type { uint, {  }*, uint, uint, i8*, i8*, i8* }
 ...
 ;;
 ;; Define the anchor for compile units.  Note that the second field of the
@@ -1039,35 +1167,36 @@ int main(int argc, char *argv[]) {
 ;; Define the compile unit for the source file "/Users/mine/sources/MySource.cpp".
 ;;
 %llvm.dbg.compile_unit1 = internal constant %llvm.dbg.compile_unit.type {
-    uint 17, 
+    uint add(uint 17, uint 262144), 
     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to {  }*), 
     uint 1, 
     uint 1, 
-    sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0), 
-    sbyte* getelementptr ([21 x sbyte]* %str2, int 0, int 0), 
-    sbyte* getelementptr ([33 x sbyte]* %str3, int 0, int 0) }, section "llvm.metadata"
+    i8* getelementptr ([13 x i8]* %str1, i32 0, i32 0), 
+    i8* getelementptr ([21 x i8]* %str2, i32 0, i32 0), 
+    i8* getelementptr ([33 x i8]* %str3, i32 0, i32 0) }, section "llvm.metadata"
     
 ;;
 ;; Define the compile unit for the header file "/Users/mine/sources/MyHeader.h".
 ;;
 %llvm.dbg.compile_unit2 = internal constant %llvm.dbg.compile_unit.type {
-    uint 17, 
+    uint add(uint 17, uint 262144), 
     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.compile_units to {  }*), 
     uint 1, 
     uint 1, 
-    sbyte* getelementptr ([11 x sbyte]* %str4, int 0, int 0), 
-    sbyte* getelementptr ([21 x sbyte]* %str2, int 0, int 0), 
-    sbyte* getelementptr ([33 x sbyte]* %str3, int 0, int 0) }, section "llvm.metadata"
+    i8* getelementptr ([11 x i8]* %str4, int 0, int 0), 
+    i8* getelementptr ([21 x i8]* %str2, int 0, int 0), 
+    i8* getelementptr ([33 x i8]* %str3, int 0, int 0) }, section "llvm.metadata"
 
 ;;
 ;; Define each of the strings used in the compile units.
 ;;
-%str1 = internal constant [13 x sbyte] c"MySource.cpp\00", section "llvm.metadata";
-%str2 = internal constant [21 x sbyte] c"/Users/mine/sources/\00", section "llvm.metadata";
-%str3 = internal constant [33 x sbyte] c"4.0.1 LLVM (LLVM research group)\00", section "llvm.metadata";
-%str4 = internal constant [11 x sbyte] c"MyHeader.h\00", section "llvm.metadata";
+%str1 = internal constant [13 x i8] c"MySource.cpp\00", section "llvm.metadata";
+%str2 = internal constant [21 x i8] c"/Users/mine/sources/\00", section "llvm.metadata";
+%str3 = internal constant [33 x i8] c"4.0.1 LLVM (LLVM research group)\00", section "llvm.metadata";
+%str4 = internal constant [11 x i8] c"MyHeader.h\00", section "llvm.metadata";
 ...
+
@@ -1078,14 +1207,17 @@ int main(int argc, char *argv[]) {
-

Given an integer global variable declared as follows;

+

Given an integer global variable declared as follows:

+
 int MyGlobal = 100;
+
-

a C/C++ front-end would generate the following descriptors;

+

a C/C++ front-end would generate the following descriptors:

+
 ;;
 ;; Define types used. One for global variable anchors, one for the global
@@ -1093,8 +1225,8 @@ int MyGlobal = 100;
 ;; compile unit.
 ;;
 %llvm.dbg.anchor.type = type { uint, uint }
-%llvm.dbg.global_variable.type = type { uint, {  }*, {  }*, sbyte*, {  }*, uint, {  }*, bool, bool, {  }*, uint }
-%llvm.dbg.basictype.type = type { uint, {  }*, sbyte*, {  }*, int, uint, uint, uint, uint }
+%llvm.dbg.global_variable.type = type { uint, {  }*, {  }*, i8*, {  }*, uint, {  }*, bool, bool, {  }*, uint }
+%llvm.dbg.basictype.type = type { uint, {  }*, i8*, {  }*, int, uint, uint, uint, uint }
 %llvm.dbg.compile_unit.type = ...
 ...
 ;;
@@ -1114,10 +1246,11 @@ int MyGlobal = 100;
 ;; variable anchor and the global variable itself.
 ;;
 %llvm.dbg.global_variable = internal constant %llvm.dbg.global_variable.type {
-    uint 52, 
+    uint add(uint 52, uint 262144), 
     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.global_variables to {  }*), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([9 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([9 x i8]* %str1, int 0, int 0), 
+    i8* getelementptr ([1 x i8]* %str2, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     uint 1,
     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*), 
@@ -1130,9 +1263,9 @@ int MyGlobal = 100;
 ;; intrinsic type the source file is NULL and line 0.
 ;;    
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([4 x sbyte]* %str2, int 0, int 0), 
+    i8* getelementptr ([4 x i8]* %str3, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
@@ -1143,9 +1276,11 @@ int MyGlobal = 100;
 ;;
 ;; Define the names of the global variable and basic type.
 ;;
-%str1 = internal constant [9 x sbyte] c"MyGlobal\00", section "llvm.metadata"
-%str2 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
+%str1 = internal constant [9 x i8] c"MyGlobal\00", section "llvm.metadata"
+%str2 = internal constant [1 x i8] c"\00", section "llvm.metadata"
+%str3 = internal constant [4 x i8] c"int\00", section "llvm.metadata"
+
@@ -1156,23 +1291,26 @@ int MyGlobal = 100;
-

Given a function declared as follows;

+

Given a function declared as follows:

+
 int main(int argc, char *argv[]) {
   return 0;
 }
+
-

a C/C++ front-end would generate the following descriptors;

+

a C/C++ front-end would generate the following descriptors:

+
 ;;
 ;; Define types used. One for subprogram anchors, one for the subprogram
 ;; descriptor, one for the global's basic type and one for the subprogram's
 ;; compile unit.
 ;;
-%llvm.dbg.subprogram.type = type { uint, {  }*, {  }*, sbyte*, {  }*, bool, bool }
+%llvm.dbg.subprogram.type = type { uint, {  }*, {  }*, i8*, {  }*, bool, bool }
 %llvm.dbg.anchor.type = type { uint, uint }
 %llvm.dbg.compile_unit.type = ...
 	
@@ -1187,10 +1325,11 @@ int main(int argc, char *argv[]) {
 ;; Define the descriptor for the subprogram.  TODO - more details.
 ;;
 %llvm.dbg.subprogram = internal constant %llvm.dbg.subprogram.type {
-    uint 46, 
+    uint add(uint 46, uint 262144), 
     {  }* cast (%llvm.dbg.anchor.type* %llvm.dbg.subprograms to {  }*), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([5 x i8]* %str1, int 0, int 0), 
+    i8* getelementptr ([1 x i8]* %str2, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*),
     uint 1,
     {  }* null, 
@@ -1200,15 +1339,17 @@ int main(int argc, char *argv[]) {
 ;;
 ;; Define the name of the subprogram.
 ;;
-%str1 = internal constant [5 x sbyte] c"main\00", section "llvm.metadata"
+%str1 = internal constant [5 x i8] c"main\00", section "llvm.metadata"
+%str2 = internal constant [1 x i8] c"\00", section "llvm.metadata"
 
 ;;
 ;; Define the subprogram itself.
 ;;
-int %main(int %argc, sbyte** %argv) {
+int %main(int %argc, i8** %argv) {
 ...
 }
+
@@ -1219,7 +1360,7 @@ int %main(int %argc, sbyte** %argv) {
-

The following are the basic type descriptors for C/C++ core types;

+

The following are the basic type descriptors for C/C++ core types:

@@ -1230,19 +1371,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([5 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
     uint 32, 
     uint 0, 
     uint 2 }, section "llvm.metadata"
-%str1 = internal constant [5 x sbyte] c"bool\00", section "llvm.metadata"
+%str1 = internal constant [5 x i8] c"bool\00", section "llvm.metadata"
+
@@ -1253,19 +1396,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([5 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 8, 
     uint 8, 
     uint 0, 
     uint 6 }, section "llvm.metadata"
-%str1 = internal constant [5 x sbyte] c"char\00", section "llvm.metadata"
+%str1 = internal constant [5 x i8] c"char\00", section "llvm.metadata"
+
@@ -1276,19 +1421,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([14 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([14 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 8, 
     uint 8, 
     uint 0, 
     uint 8 }, section "llvm.metadata"
-%str1 = internal constant [14 x sbyte] c"unsigned char\00", section "llvm.metadata"
+%str1 = internal constant [14 x i8] c"unsigned char\00", section "llvm.metadata"
+
@@ -1299,19 +1446,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([10 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([10 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 16, 
     uint 16, 
     uint 0, 
     uint 5 }, section "llvm.metadata"
-%str1 = internal constant [10 x sbyte] c"short int\00", section "llvm.metadata"
+%str1 = internal constant [10 x i8] c"short int\00", section "llvm.metadata"
+
@@ -1322,19 +1471,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([19 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([19 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 16, 
     uint 16, 
     uint 0, 
     uint 7 }, section "llvm.metadata"
-%str1 = internal constant [19 x sbyte] c"short unsigned int\00", section "llvm.metadata"
+%str1 = internal constant [19 x i8] c"short unsigned int\00", section "llvm.metadata"
+
@@ -1345,19 +1496,20 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([4 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([4 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
     uint 32, 
     uint 0, 
     uint 5 }, section "llvm.metadata"
-%str1 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
-
+%str1 = internal constant [4 x i8] c"int\00", section "llvm.metadata" +
@@ -1368,19 +1520,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([13 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
     uint 32, 
     uint 0, 
     uint 7 }, section "llvm.metadata"
-%str1 = internal constant [13 x sbyte] c"unsigned int\00", section "llvm.metadata"
+%str1 = internal constant [13 x i8] c"unsigned int\00", section "llvm.metadata"
+
@@ -1391,19 +1545,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([14 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([14 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 64, 
     uint 64, 
     uint 0, 
     uint 5 }, section "llvm.metadata"
-%str1 = internal constant [14 x sbyte] c"long long int\00", section "llvm.metadata"
+%str1 = internal constant [14 x i8] c"long long int\00", section "llvm.metadata"
+
@@ -1414,19 +1570,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([23 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([23 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 64, 
     uint 64, 
     uint 0, 
     uint 7 }, section "llvm.metadata"
-%str1 = internal constant [23 x sbyte] c"long long unsigned int\00", section "llvm.metadata"
+%str1 = internal constant [23 x 8] c"long long unsigned int\00", section "llvm.metadata"
+
@@ -1437,19 +1595,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([6 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([6 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
     uint 32, 
     uint 0, 
     uint 4 }, section "llvm.metadata"
-%str1 = internal constant [6 x sbyte] c"float\00", section "llvm.metadata"
+%str1 = internal constant [6 x i8] c"float\00", section "llvm.metadata"
+
@@ -1460,19 +1620,21 @@ int %main(int %argc, sbyte** %argv) {
+
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([7 x sbyte]* %str1, int 0, int 0), 
+    8* getelementptr ([7 x 8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 64, 
     uint 64, 
     uint 0, 
     uint 4 }, section "llvm.metadata"
-%str1 = internal constant [7 x sbyte] c"double\00", section "llvm.metadata"
+%str1 = internal constant [7 x 8] c"double\00", section "llvm.metadata"
+
@@ -1483,37 +1645,40 @@ int %main(int %argc, sbyte** %argv) {
-

Given the following as an example of C/C++ derived type;

+

Given the following as an example of C/C++ derived type:

+
 typedef const int *IntPtr;
+
-

a C/C++ front-end would generate the following descriptors;

+

a C/C++ front-end would generate the following descriptors:

+
 ;;
 ;; Define the typedef "IntPtr".
 ;;
 %llvm.dbg.derivedtype1 = internal constant %llvm.dbg.derivedtype.type {
-    uint 22, 
+    uint add(uint 22, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([7 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([7 x 8]* %str1, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     int 1, 
     uint 0, 
     uint 0, 
     uint 0, 
     {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype2 to {  }*) }, section "llvm.metadata"
-%str1 = internal constant [7 x sbyte] c"IntPtr\00", section "llvm.metadata"
+%str1 = internal constant [7 x 8] c"IntPtr\00", section "llvm.metadata"
 
 ;;
 ;; Define the pointer type.
 ;;
 %llvm.dbg.derivedtype2 = internal constant %llvm.dbg.derivedtype.type {
-    uint 15, 
+    uint add(uint 15, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* null, 
+    i8* null, 
     {  }* null, 
     int 0, 
     uint 32, 
@@ -1525,9 +1690,9 @@ typedef const int *IntPtr;
 ;; Define the const type.
 ;;
 %llvm.dbg.derivedtype3 = internal constant %llvm.dbg.derivedtype.type {
-    uint 38, 
+    uint add(uint 38, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* null, 
+    i8* null, 
     {  }* null, 
     int 0, 
     uint 0, 
@@ -1539,17 +1704,18 @@ typedef const int *IntPtr;
 ;; Define the int type.
 ;;
 %llvm.dbg.basictype1 = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([4 x sbyte]* %str2, int 0, int 0), 
+    8* getelementptr ([4 x 8]* %str2, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
     uint 32, 
     uint 0, 
     uint 5 }, section "llvm.metadata"
-%str2 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
+%str2 = internal constant [4 x 8] c"int\00", section "llvm.metadata"
+
@@ -1560,8 +1726,9 @@ typedef const int *IntPtr;
-

Given the following as an example of C/C++ struct type;

+

Given the following as an example of C/C++ struct type:

+
 struct Color {
   unsigned Red;
@@ -1569,85 +1736,87 @@ struct Color {
   unsigned Blue;
 };
+
-

a C/C++ front-end would generate the following descriptors;

+

a C/C++ front-end would generate the following descriptors:

+
 ;;
 ;; Define basic type for unsigned int.
 ;;
 %llvm.dbg.basictype = internal constant %llvm.dbg.basictype.type {
-    uint 36, 
+    uint add(uint 36, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([13 x i8]* %str1, int 0, int 0), 
     {  }* null, 
     int 0, 
     uint 32, 
     uint 32, 
     uint 0, 
     uint 7 }, section "llvm.metadata"
-%str1 = internal constant [13 x sbyte] c"unsigned int\00", section "llvm.metadata"
+%str1 = internal constant [13 x i8] c"unsigned int\00", section "llvm.metadata"
 
 ;;
 ;; Define composite type for struct Color.
 ;;
 %llvm.dbg.compositetype = internal constant %llvm.dbg.compositetype.type {
-    uint 19, 
+    uint add(uint 19, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([6 x sbyte]* %str2, int 0, int 0), 
+    i8* getelementptr ([6 x i8]* %str2, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     int 1, 
     uint 96, 
     uint 32, 
     uint 0, 
-    {  }* null, 
+    {  }* null,
     {  }* cast ([3 x {  }*]* %llvm.dbg.array to {  }*) }, section "llvm.metadata"
-%str2 = internal constant [6 x sbyte] c"Color\00", section "llvm.metadata"
+%str2 = internal constant [6 x i8] c"Color\00", section "llvm.metadata"
 
 ;;
 ;; Define the Red field.
 ;;
 %llvm.dbg.derivedtype1 = internal constant %llvm.dbg.derivedtype.type {
-    uint 13, 
+    uint add(uint 13, uint 262144), 
     {  }* null, 
-    sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0), 
+    i8* getelementptr ([4 x i8]* %str3, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     int 2, 
     uint 32, 
     uint 32, 
     uint 0, 
     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*) }, section "llvm.metadata"
-%str3 = internal constant [4 x sbyte] c"Red\00", section "llvm.metadata"
+%str3 = internal constant [4 x i8] c"Red\00", section "llvm.metadata"
 
 ;;
 ;; Define the Green field.
 ;;
 %llvm.dbg.derivedtype2 = internal constant %llvm.dbg.derivedtype.type {
-    uint 13, 
+    uint add(uint 13, uint 262144), 
     {  }* null, 
-    sbyte* getelementptr ([6 x sbyte]* %str4, int 0, int 0), 
+    i8* getelementptr ([6 x i8]* %str4, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     int 3, 
     uint 32, 
     uint 32, 
     uint 32, 
     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*) }, section "llvm.metadata"
-%str4 = internal constant [6 x sbyte] c"Green\00", section "llvm.metadata"
+%str4 = internal constant [6 x i8] c"Green\00", section "llvm.metadata"
 
 ;;
 ;; Define the Blue field.
 ;;
 %llvm.dbg.derivedtype3 = internal constant %llvm.dbg.derivedtype.type {
-    uint 13, 
+    uint add(uint 13, uint 262144), 
     {  }* null, 
-    sbyte* getelementptr ([5 x sbyte]* %str5, int 0, int 0), 
+    i8* getelementptr ([5 x i8]* %str5, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     int 4, 
     uint 32, 
     uint 32, 
     uint 64, 
     {  }* cast (%llvm.dbg.basictype.type* %llvm.dbg.basictype to {  }*) }, section "llvm.metadata"
-%str5 = internal constant [5 x sbyte] c"Blue\00", section "llvm.metadata"
+%str5 = internal constant [5 x 8] c"Blue\00", section "llvm.metadata"
 
 ;;
 ;; Define the array of fields used by the composite type Color.
@@ -1657,6 +1826,7 @@ struct Color {
       {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype2 to {  }*),
       {  }* cast (%llvm.dbg.derivedtype.type* %llvm.dbg.derivedtype3 to {  }*) ], section "llvm.metadata"
+
@@ -1667,8 +1837,9 @@ struct Color {
-

Given the following as an example of C/C++ enumeration type;

+

Given the following as an example of C/C++ enumeration type:

+
 enum Trees {
   Spruce = 100,
@@ -1676,17 +1847,19 @@ enum Trees {
   Maple = 300
 };
+
-

a C/C++ front-end would generate the following descriptors;

+

a C/C++ front-end would generate the following descriptors:

+
 ;;
 ;; Define composite type for enum Trees
 ;;
 %llvm.dbg.compositetype = internal constant %llvm.dbg.compositetype.type {
-    uint 4, 
+    uint add(uint 4, uint 262144), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
-    sbyte* getelementptr ([6 x sbyte]* %str1, int 0, int 0), 
+    i8* getelementptr ([6 x i8]* %str1, int 0, int 0), 
     {  }* cast (%llvm.dbg.compile_unit.type* %llvm.dbg.compile_unit to {  }*), 
     int 1, 
     uint 32, 
@@ -1694,34 +1867,34 @@ enum Trees {
     uint 0, 
     {  }* null, 
     {  }* cast ([3 x {  }*]* %llvm.dbg.array to {  }*) }, section "llvm.metadata"
-%str1 = internal constant [6 x sbyte] c"Trees\00", section "llvm.metadata"
+%str1 = internal constant [6 x i8] c"Trees\00", section "llvm.metadata"
 
 ;;
 ;; Define Spruce enumerator.
 ;;
 %llvm.dbg.enumerator1 = internal constant %llvm.dbg.enumerator.type {
-    uint 40, 
-    sbyte* getelementptr ([7 x sbyte]* %str2, int 0, int 0), 
+    uint add(uint 40, uint 262144), 
+    i8* getelementptr ([7 x i8]* %str2, int 0, int 0), 
     int 100 }, section "llvm.metadata"
-%str2 = internal constant [7 x sbyte] c"Spruce\00", section "llvm.metadata"
+%str2 = internal constant [7 x i8] c"Spruce\00", section "llvm.metadata"
 
 ;;
 ;; Define Oak enumerator.
 ;;
 %llvm.dbg.enumerator2 = internal constant %llvm.dbg.enumerator.type {
-    uint 40, 
-    sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0), 
+    uint add(uint 40, uint 262144), 
+    i8* getelementptr ([4 x i8]* %str3, int 0, int 0), 
     int 200 }, section "llvm.metadata"
-%str3 = internal constant [4 x sbyte] c"Oak\00", section "llvm.metadata"
+%str3 = internal constant [4 x i8] c"Oak\00", section "llvm.metadata"
 
 ;;
 ;; Define Maple enumerator.
 ;;
 %llvm.dbg.enumerator3 = internal constant %llvm.dbg.enumerator.type {
-    uint 40, 
-    sbyte* getelementptr ([6 x sbyte]* %str4, int 0, int 0), 
+    uint add(uint 40, uint 262144), 
+    i8* getelementptr ([6 x i8]* %str4, int 0, int 0), 
     int 300 }, section "llvm.metadata"
-%str4 = internal constant [6 x sbyte] c"Maple\00", section "llvm.metadata"
+%str4 = internal constant [6 x i8] c"Maple\00", section "llvm.metadata"
 
 ;;
 ;; Define the array of enumerators used by composite type Trees.
@@ -1731,6 +1904,7 @@ enum Trees {
   {  }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator2 to {  }*),
   {  }* cast (%llvm.dbg.enumerator.type* %llvm.dbg.enumerator3 to {  }*) ], section "llvm.metadata"
+
@@ -1739,9 +1913,9 @@ enum Trees {
Valid CSS! + src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"> Valid HTML 4.01! + src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
LLVM Compiler Infrastructure