llvm.org GIT mirror llvm / 8287373
Made file comply with HTML-4.01 (Strict) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13503 91177308-0d34-0410-b5e6-96231b3b80d8 Misha Brukman 15 years ago
1 changed file(s) with 209 addition(s) and 264 deletion(s). Raw diff Collapse all Expand all
88
99
Source Level Debugging with LLVM
1010
11
12
13
1114
1215
13 A leafy and green bug eater
14 width=247 height=369 align=right>
15
16
  • Introduction
  • 16
  • Introduction
  • 1717
    1818
  • Philosophy behind LLVM debugging information
  • 1919
  • Debugging optimized code
  • 2020
  • Future work
  • 21
    21
    2222
  • Using the llvm-db tool
  • 2323
    2424
  • Limitations of llvm-db
  • 2727
  • Commands recognized by the debugger
  • 2828
    2929
    30
  • Architecture of the LLVM debugger
  • 30
  • Architecture of the LLVM debugger
  • 3131
    3232
  • The Debugger and InferiorProcess classes
  • 3333
  • The RuntimeInfo, ProgramInfo, and SourceLanguage classes
  • 3434
  • The llvm-db tool
  • 3535
  • Short-term TODO list
  • 36
    37
    38 <li>Debugging information format>
    36 </ol>
    37
    38
  • Debugging information format
  • 3939
    4040
  • Anchors for global objects
  • 4141
  • Representing stopping points in the source program
  • 4242
  • Object lifetimes and scoping
  • 43
  • Object descriptor formats
  • 43
  • Object descriptor formats
  • 4444
    4545
  • Representation of source files
  • 4646
  • Representation of program objects
  • 4747
  • Program object contexts
  • 48
    48
    4949
  • Debugger intrinsic functions
  • 5050
  • Values for debugger tags
  • 51
    52 <li>C/C++ front-end specific debug information>
    51 </ol>
    52
  • C/C++ front-end specific debug information
  • 5353
    54
  • Program Scope Entries
  • 54
  • Program Scope Entries
  • 5555
    5656
  • Compilation unit entries
  • 5757
  • Module, namespace, and importing entries
  • 58
    58
    5959
  • Data objects (program variables)
  • 60
    60
    6161
    62
    63
    64 A leafy and green bug eater
    65 height="369">
    66
    67
    68
    69
    6270
    6371
    64
    65 <!-- *********************************************************************** -->
    72 <div class="doc_section">Introduction
    6674
    6775
    6876
    8694
    8795
    8896
    89

    90 The idea of the LLVM debugging information is to capture how the important
    97

    The idea of the LLVM debugging information is to capture how the important

    9198 pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
    9299 Several design aspects have shaped the solution that appears here. The
    93100 important ones are:

    94101
    95 <p><ul>
    102 <ul>
    96103
  • Debugging information should have very little impact on the rest of the
  • 97104 compiler. No transformations, analyses, or code generators should need to be
    98105 modified because of debugging information.
    113120 This allows compatibility with traditional machine-code level debuggers, like
    114121 GDB or DBX.
    115122
    116

    117
    118

    119 The approach used by the LLVM implementation is to use a small set of
    123
    124
    125

    The approach used by the LLVM implementation is to use a small set of

    120126 href="#format_common_intrinsics">intrinsic functions to define a mapping
    121127 between LLVM program objects and the source-level objects. The description of
    122128 the source-level program is maintained in LLVM global variables in an
    124130 currently uses working draft 7 of the
    125131 href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3 standard).

    126132
    127

    128 When a program is debugged, the debugger interacts with the user and turns the
    129 stored debug information into source-language specific information. As such,
    130 the debugger must be aware of the source-language, and is thus tied to a
    133

    When a program is debugged, the debugger interacts with the user and turns

    134 the stored debug information into source-language specific information. As
    135 such, the debugger must be aware of the source-language, and is thus tied to a
    131136 specific language of family of languages. The LLVM
    132 debugger is designed to be modular in its support for source-languages.
    133

    137 debugger is designed to be modular in its support for source-languages.

    134138
    135139
    136140
    141145
    142146
    143147
    144

    145 An extremely high priority of LLVM debugging information is to make it interact
    146 well with optimizations and analysis. In particular, the LLVM debug information
    147 provides the following guarantees:

    148
    149

    148
    149

    An extremely high priority of LLVM debugging information is to make it

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

    152
    153
    150154
    151155
  • LLVM debug information always provides information to accurately read the
  • 152156 source-level state of the program, regardless of which LLVM optimizations
    175179 automatically merged by the linker, and unused information is automatically
    176180 removed.
    177181
    178

    179
    180

    181 Basically, the debug information allows you to compile a program with "-O0
    182 -g" and get full debug information, allowing you to arbitrarily modify the
    183 program as it executes from the debugger. Compiling a program with "-O3
    184 -g" gives you full debug information that is always available and accurate
    185 for reading (e.g., you get accurate stack traces despite tail call elimination
    186 and inlining), but you might lose the ability to modify the program and call
    187 functions where were optimized out of the program, or inlined away completely.
    188

    189
    190
    191
    182
    183
    184

    Basically, the debug information allows you to compile a program with

    185 "-O0 -g" and get full debug information, allowing you to arbitrarily
    186 modify the program as it executes from the debugger. Compiling a program with
    187 "-O3 -g" gives you full debug information that is always available and
    188 accurate for reading (e.g., you get accurate stack traces despite tail call
    189 elimination and inlining), but you might lose the ability to modify the program
    190 and call functions where were optimized out of the program, or inlined away
    191 completely.

    192
    193
    192194
    193195
    194196
    196198
    197199
    198200
    199

    200 There are several important extensions that could be eventually added to the
    201

    There are several important extensions that could be eventually added to the

    201202 LLVM debugger. The most important extension would be to upgrade the LLVM code
    202203 generators to support debugging information. This would also allow, for
    203204 example, the X86 code generator to emit native objects that contain debugging
    204205 information consumable by traditional source-level debuggers like GDB or
    205206 DBX.

    206207
    207

    208 Additionally, LLVM optimizations can be upgraded to incrementally update the
    208

    Additionally, LLVM optimizations can be upgraded to incrementally update the

    209209 debugging information, new commands can be added to the
    210210 debugger, and thread support could be added to the debugger.

    211211
    212

    213 The "SourceLanguage" modules provided by llvm-db could be substantially
    214 improved to provide good support for C++ language features like namespaces and
    215 scoping rules.

    216
    217

    218 After working with the debugger for a while, perhaps the nicest improvement
    212

    The "SourceLanguage" modules provided by llvm-db could be

    213 substantially improved to provide good support for C++ language features like
    214 namespaces and scoping rules.

    215
    216

    After working with the debugger for a while, perhaps the nicest improvement

    219217 would be to add some sort of line editor, such as GNU readline (but one that is
    220218 compatible with the LLVM license).

    221219
    222

    223 For someone so inclined, it should be straight-forward to write different
    220

    For someone so inclined, it should be straight-forward to write different

    224221 front-ends for the LLVM debugger, as the LLVM debugging engine is cleanly
    225222 separated from the llvm-db front-end. A new LLVM GUI debugger or IDE
    226 would be nice. :)
    227

    228
    229
    230
    223 would be nice. :)

    224
    225
    231226
    232227
    233228
    237232
    238233
    239234
    240

    241 The llvm-db tool provides a GDB-like interface for source-level
    235

    The llvm-db tool provides a GDB-like interface for source-level

    242236 debugging of programs. This tool provides many standard commands for inspecting
    243237 and modifying the program as it executes, loading new programs, single stepping,
    244 placing breakpoints, etc. This section describes how to use the debugger.
    245

    238 placing breakpoints, etc. This section describes how to use the debugger.

    246239
    247240

    llvm-db has been designed to be as similar to GDB in its user

    248241 interface as possible. This should make it extremely easy to learn
    272265 any cooperation from the code generators. Because it is so simple, it suffers
    273266 from the following inherent limitations:

    274267
    275 <p><ul>
    268 <ul>
    276269
    277270
  • Running a program in llvm-db is a bit slower than running it with
  • 278271 lli (i.e., in the JIT).
    291284
  • Attaching to existing processes and core files is not currently
  • 292285 supported.
    293286
    294

    287
    295288
    296289

    That said, the debugger is still quite useful, and all of these limitations

    297290 can be eliminated by integrating support for the debugger into the code
    312305

    TODO: this is obviously lame, when more is implemented, this can be much

    313306 better.

    314307
    315 >re>
    308 re>
    316309 $ llvm-db funccall
    317310 llvm-db: The LLVM source-level debugger
    318311 Loading program... successfully loaded 'funccall.bc'!
    350343 The program stopped with exit code 0
    351344 (llvm-db) quit
    352345 $
    353

    346
    354347
    355348
    356349
    458451
  • info catch
  • 459452
  • ... many others
  • 460453
    461

    454
    462455
    463456
    464457
    468461
    469462
    470463
    471
    472

    473 The LLVM debugger is built out of three distinct layers of software. These
    464

    The LLVM debugger is built out of three distinct layers of software. These

    474465 layers provide clients with different interface options depending on what pieces
    475466 of they want to implement themselves, and it also promotes code modularity and
    476467 good design. The three layers are the Debugger
    477 interface, the "info" interfaces, and the
    478 llvm-db tool itself.
    479

    468 interface, the "info" interfaces, and the
    469 href="#arch_llvm-db">llvm-db tool itself.

    480470
    481471
    482472
    485475
    486476
    487477
    488

    489 The Debugger class (defined in the include/llvm/Debugger/ directory) is
    490 a low-level class which is used to maintain information about the loaded
    478

    The Debugger class (defined in the include/llvm/Debugger/ directory)

    479 is a low-level class which is used to maintain information about the loaded
    491480 program, as well as start and stop the program running as necessary. This class
    492481 does not provide any high-level analysis or control over the program, only
    493482 exposing simple interfaces like load/unloadProgram,
    494483 create/killProgram, step/next/finish/contProgram, and
    495 low-level methods for installing breakpoints.
    496

    484 low-level methods for installing breakpoints.

    497485
    498486

    499487 The Debugger class is itself a wrapper around the lowest-level InferiorProcess
    655643 module to decode the information that represents variables, types,
    656644 functions, namespaces, etc: this allows for arbitrary source-language semantics
    657645 and type-systems to be used, as long as there is a module written for the
    658 debugger to interpret the information.
    659

    660
    661

    662 To provide basic functionality, the LLVM debugger does have to make some
    646 debugger to interpret the information.

    647
    648

    To provide basic functionality, the LLVM debugger does have to make some

    663649 assumptions about the source-level language being debugged, though it keeps
    664650 these to a minimum. The only common features that the LLVM debugger assumes
    665651 exist are source files, and
    666652 href="#format_program_objects">program objects. These abstract objects are
    667653 used by the debugger to form stack traces, show information about local
    668 variables, etc.
    654 variables, etc.

    669655
    670656

    This section of the documentation first describes the representation aspects

    671657 common to any source-language. The next section
    679665
    680666
    681667
    682

    683 One important aspect of the LLVM debug representation is that it allows the LLVM
    684 debugger to efficiently index all of the global objects without having the scan
    685 the program. To do this, all of the global objects use "anchor" globals of type
    686 "{}", with designated names. These anchor objects obviously do not
    687 contain any content or meaning by themselves, but all of the global objects of a
    688 particular type (e.g., source file descriptors) contain a pointer to the anchor.
    689 This pointer allows the debugger to use def-use chains to find all global
    690 objects of that type.
    691

    692
    693

    694 So far, the following names are recognized as anchors by the LLVM debugger:
    695

    696
    697

    
                      
                    
    668

    One important aspect of the LLVM debug representation is that it allows the

    669 LLVM debugger to efficiently index all of the global objects without having the
    670 scan the program. To do this, all of the global objects use "anchor" globals of
    671 type "{}", with designated names. These anchor objects obviously do
    672 not contain any content or meaning by themselves, but all of the global objects
    673 of a particular type (e.g., source file descriptors) contain a pointer to the
    674 anchor. This pointer allows the debugger to use def-use chains to find all
    675 global objects of that type.

    676
    677

    So far, the following names are recognized as anchors by the LLVM

    678 debugger:

    679
    680
    
                      
                    
    698681 %llvm.dbg.translation_units = linkonce global {} {}
    699682 %llvm.dbg.globals = linkonce global {} {}
    700

    701
    702

    703 Using anchors in this way (where the source file descriptor points to the
    683
    684
    685

    Using anchors in this way (where the source file descriptor points to the

    704686 anchors, as opposed to having a list of source file descriptors) allows for the
    705687 standard dead global elimination and merging passes to automatically remove
    706688 unused debugging information. If the globals were kept track of through lists,
    707689 there would always be an object pointing to the descriptors, thus would never be
    708 deleted.
    709

    710
    711
    712
    690 deleted.

    691
    692
    713693
    714694
    715695
    731711 recommended to only put them after every source statement that includes
    732712 executable code.

    733713
    734

    735 Using calls to this intrinsic function to demark legal points for the debugger
    736 to inspect the program automatically disables any optimizations that could
    737 potentially confuse debugging information. To non-debug-information-aware
    714

    Using calls to this intrinsic function to demark legal points for the

    715 debugger to inspect the program automatically disables any optimizations that
    716 could potentially confuse debugging information. To non-debug-information-aware
    738717 transformations, these calls simply look like calls to an external function,
    739718 which they must assume to do anything (including reading or writing to any part
    740719 of reachable memory). On the other hand, it does not impact many optimizations,
    742721 optimization of subexpressions, code duplication transformations, or basic-block
    743722 reordering transformations.

    744723
    745

    746 An important aspect of the calls to the %llvm.dbg.stoppoint intrinsic
    747 is that the function-local debugging information is woven together with use-def
    748 chains. This makes it easy for the debugger to, for example, locate the 'next'
    749 stop point. For a concrete example of stop points, see the example in
    750 href="#format_common_lifetime">the next section.>
    724

    An important aspect of the calls to the %llvm.dbg.stoppoint>

    725 intrinsic is that the function-local debugging information is woven together
    726 with use-def chains. This makes it easy for the debugger to, for example,
    727 locate the 'next' stop point. For a concrete example of stop points, see the
    728 example in the next section.

    751729
    752730
    753731
    758736
    759737
    760738
    761

    762 In many languages, the local variables in functions can have their lifetime or
    763 scope limited to a subset of a function. In the C family of languages, for
    739

    In many languages, the local variables in functions can have their lifetime

    740 or scope limited to a subset of a function. In the C family of languages, for
    764741 example, variables are only live (readable and writable) within the source block
    765742 that they are defined in. In functional languages, values are only readable
    766743 after they have been defined. Though this is a very obvious concept, it is also
    767744 non-trivial to model in LLVM, because it has no notion of scoping in this sense,
    768 and does not want to be tied to a language's scoping rules.
    769

    770
    771

    772 In order to handle this, the LLVM debug format uses the notion of "regions" of a
    773 function, delineated by calls to intrinsic functions. These intrinsic functions
    774 define new regions of the program and indicate when the region lifetime expires.
    775 Consider the following C fragment, for example:
    776

    777
    778

    >

    745 and does not want to be tied to a language's scoping rules.>
    746
    747

    In order to handle this, the LLVM debug format uses the notion of "regions"

    748 of a function, delineated by calls to intrinsic functions. These intrinsic
    749 functions define new regions of the program and indicate when the region
    750 lifetime expires. Consider the following C fragment, for example:

    751
    752
    
                      
                    
    779753 1. void foo() {
    780754 2. int X = ...;
    781755 3. int Y = ...;
    785759 7. }
    786760 8. ...
    787761 9. }
    788

    789
    790

    791 Compiled to LLVM, this function would be represented like this (FIXME: CHECK AND
    792 UPDATE THIS):
    793

    794
    795 <p><pre>
    762 </pre>
    763
    764

    Compiled to LLVM, this function would be represented like this (FIXME: CHECK

    765 AND UPDATE THIS):

    766
    767
    
                      
                    
    796768 void %foo() {
    797769 %X = alloca int
    798770 %Y = alloca int
    821793 %D12 = call {}* %llvm.region.end({}* %D11)
    822794 ret void
    823795 }
    824

    825
    826

    827 This example illustrates a few important details about the LLVM debugging
    796
    797
    798

    This example illustrates a few important details about the LLVM debugging

    828799 information. In particular, it shows how the various intrinsics used are woven
    829800 together with def-use and use-def chains, similar to how
    830 href="#format_common_anchors">anchors are used with globals. This allows the
    831 debugger to analyze the relationship between statements, variable definitions,
    832 and the code used to implement the function.

    833
    834

    835 In this example, two explicit regions are defined, one with the
    801 href="#format_common_anchors">anchors are used with globals. This allows
    802 the debugger to analyze the relationship between statements, variable
    803 definitions, and the code used to implement the function.

    804
    805

    In this example, two explicit regions are defined, one with the

    836806 href="#icl_ex_D1">definition of the %D1 variable and one with the
    837807 definition of %D7. In the case of
    838808 %D1, the debug information indicates that the function whose
    840810 intrinsic. This defines a new stack frame whose lifetime ends when the region
    841811 is ended by the %D12 call.

    842812
    843

    844 Using regions to represent the boundaries of source-level functions allow LLVM
    845 interprocedural optimizations to arbitrarily modify LLVM functions without
    813

    Using regions to represent the boundaries of source-level functions allow

    814 LLVM interprocedural optimizations to arbitrarily modify LLVM functions without
    846815 having to worry about breaking mapping information between the LLVM code and the
    847816 and source-level program. In particular, the inliner requires no modification
    848817 to support inlining with debugging information: there is no explicit correlation
    851820 its caller that it will not be possible for the user to manually invoke the
    852821 inlined function from the debugger).

    853822
    854

    855 Once the function has been defined, the
    856 href="#format_common_stoppoint">stopping point corresponding to line #2 of the
    857 function is encountered. At this point in the function, no local
    823

    Once the function has been defined, the

    824 href="#format_common_stoppoint">stopping point corresponding to line #2 of
    825 the function is encountered. At this point in the function, no local
    858826 variables are live. As lines 2 and 3 of the example are executed, their
    859827 variable definitions are automatically introduced into the program, without the
    860828 need to specify a new region. These variables do not require new regions to be
    861829 introduced because they go out of scope at the same point in the program: line
    862 9.
    863

    864
    865

    866 In contrast, the Z variable goes out of scope at a different time, on
    867 line 7. For this reason, it is defined within the
    830 9.

    831
    832

    In contrast, the Z variable goes out of scope at a different time,

    833 on line 7. For this reason, it is defined within the
    868834 %D7 region, which kills the availability of Z before the
    869835 code for line 8 is executed. In this way, regions can support arbitrary
    870836 source-language scoping rules, as long as they can only be nested (ie, one scope
    871 cannot partially overlap with a part of another scope).
    872

    873
    874

    875 It is worth noting that this scoping mechanism is used to control scoping of all
    876 declarations, not just variable declarations. For example, the scope of a C++
    877 using declaration is controlled with this, and the llvm-db C++ support
    878 routines could use this to change how name lookup is performed (though this is
    879 not implemented yet).
    880

    881
    882
    883
    837 cannot partially overlap with a part of another scope).

    838
    839

    It is worth noting that this scoping mechanism is used to control scoping of

    840 all declarations, not just variable declarations. For example, the scope of a
    841 C++ using declaration is controlled with this, and the llvm-db C++
    842 support routines could use this to change how name lookup is performed (though
    843 this is not implemented yet).

    844
    845
    884846
    885847
    886848
    888850
    889851
    890852
    891

    892 The LLVM debugger expects the descriptors for program objects to start in a
    853

    The LLVM debugger expects the descriptors for program objects to start in a

    893854 canonical format, but the descriptors can include additional information
    894855 appended at the end that is source-language specific. All LLVM debugging
    895856 information is versioned, allowing backwards compatibility in the case that the
    905866
    906867
    907868
    908
    926
    966927
    967928 Representation of program objects
    968929
    978939 fields in the descriptor for each object:
    979940

    980941
    981 >re>
    942 re>
    982943 %lldb.object = type {
    983944 uint, ;; A tag
    984945 any*, ;; The context for the object
    985946 sbyte* ;; The object 'name'
    986947 }
    987

    988
    989

    990 The first field contains a tag for the descriptor. The second field contains
    948
    949
    950

    The first field contains a tag for the descriptor. The second field contains

    991951 either a pointer to the descriptor for the containing
    992952 href="#format_common_source_files">source file, or it contains a pointer to
    993953 another program object whose context pointer eventually reaches a source file.
    994954 Through this context pointer, the
    995955 LLVM debugger can establish the debug version number of the object.

    996956
    997

    998 The third field contains a string that the debugger can use to identify the
    957

    The third field contains a string that the debugger can use to identify the

    999958 object if it does not contain explicit support for the source-language in use
    1000959 (ie, the 'unknown' source language handler uses this string). This should be
    1001960 some sort of unmangled string that corresponds to the object, but it is a
    1002961 quality of implementation issue what exactly it contains (it is legal, though
    1003 not useful, for all of these strings to be null).
    1004

    1005
    1006

    1007 Note again that descriptors can be extended to include source-language-specific
    1008 information in addition to the fields required by the LLVM debugger. See the
    1009 href="#ccxx_descriptors">section on the C/C++ front-end for more
    1010 information. Also remember that global objects (functions, selectors, global
    1011 variables, etc) must contain an anchor to
    1012 the llvm.dbg.globals variable.
    1013

    962 not useful, for all of these strings to be null).

    963
    964

    Note again that descriptors can be extended to include

    965 source-language-specific information in addition to the fields required by the
    966 LLVM debugger. See the section on the C/C++
    967 front-end for more information. Also remember that global objects
    968 (functions, selectors, global variables, etc) must contain an
    969 href="format_common_anchors">anchor to the llvm.dbg.globals
    970 variable.

    1014971
    1015972
    1016973
    1020977
    1021978
    1022979
    1023 >re>
    980 re>
    1024981 Allow source-language specific contexts, use to identify namespaces etc
    1025982 Must end up in a source file descriptor.
    1026983 Debugger core ignores all unknown context objects.
    1027

    1028
    1029
    1030
    984
    985
    1031986
    1032987
    1033988
    1035990
    1036991
    1037992
    1038 >re>
    993 re>
    1039994 Define each intrinsics, as an extension of the language reference manual.
    1040995
    1041996 llvm.dbg.stoppoint
    1043998 llvm.dbg.region.end
    1044999 llvm.dbg.function.start
    10451000 llvm.dbg.declare
    1046

    1047
    1048
    1049
    1001
    1002
    10501003
    10511004
    10521005
    10551008
    10561009
    10571010
    1058

    1059 Happen to be the same value as the similarly named Dwarf-3 tags, this may change
    1060 in the future.
    1061

    1062
    1063

    1064

    
                      
                    
    1011

    Happen to be the same value as the similarly named Dwarf-3 tags, this may

    1012 change in the future.

    1013
    1014
    
                      
                    
    10651015 LLVM_COMPILE_UNIT : 17
    10661016 LLVM_SUBPROGRAM : 46
    10671017 LLVM_VARIABLE : 52
    10681018
    1069

    1019
    10701020
    10711021
    10721022
    10781028
    10791029
    10801030
    1081

    1082 The C and C++ front-ends represent information about the program in a format
    1031

    The C and C++ front-ends represent information about the program in a format

    10831032 that is effectively identical to
    10841033 href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3.0 in terms of
    10851034 information content. This allows code generators to trivially support native
    10861035 debuggers by generating standard dwarf information, and contains enough
    10871036 information for non-dwarf targets to translate it as needed.

    10881037
    1089

    1090 The basic debug information required by the debugger is (intentionally) designed
    1091 to be as minimal as possible. This basic information is so minimal that it is
    1092 unlikely that any source-language could be adequately described by it.
    1093 Because of this, the debugger format was designed for extension to support
    1094 source-language-specific information. The extended descriptors are read and
    1095 interpreted by the language-specific modules in the
    1096 debugger if there is support available, otherwise it is ignored.
    1097

    1098
    1099

    1100 This section describes the extensions used to represent C and C++ programs.
    1038

    The basic debug information required by the debugger is (intentionally)

    1039 designed to be as minimal as possible. This basic information is so minimal
    1040 that it is unlikely that any source-language could be adequately
    1041 described by it. Because of this, the debugger format was designed for
    1042 extension to support source-language-specific information. The extended
    1043 descriptors are read and interpreted by the
    1044 href="#arch_info">language-specific modules in the debugger if there is
    1045 support available, otherwise it is ignored.

    1046
    1047

    This section describes the extensions used to represent C and C++ programs.

    11011048 Other languages could pattern themselves after this (which itself is tuned to
    11021049 representing programs in the same way that Dwarf 3 does), or they could choose
    11031050 to provide completely different extensions if they don't fit into the Dwarf
    11041051 model. As support for debugging information gets added to the various LLVM
    1105 source-language front-ends, the information used should be documented here.
    1106

    1052 source-language front-ends, the information used should be documented here.

    11071053
    11081054
    11091055
    11131059
    11141060
    11151061
    1116

    1117
    1118

    1119
    1120
    1121 <!----------------------------------------------------------------------------->
    1062 <p>TODO>
    1063
    1064
    1065
    11221066
    11231067 Compilation unit entries
    11241068
    11321076

    11331077
    11341078
    1135
    1079
    11361080
    11371081 Module, namespace, and importing entries
    11381082
    11391083
    11401084
    1141

    1142
    1143 </p>
    1085 <p>TODO</p>
    11441086
    11451087
    11461088
    11491091
    11501092
    11511093
    1152

    1153
    1154 </p>
    1094 <p>TODO</p>
    11551095
    11561096
    11571097
    11581098
    1099
    11591100
    1160
    1161
    Chris Lattner
    1162 The LLVM Compiler Infrastructure
    1163 >
    1101 >
    1102
    1103 src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!">
    1104
    1105 src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!">
    1106
    1107 Chris Lattner
    1108 LLVM Compiler Infrastructure
    11641109 Last modified: $Date$
    1165 div>
    1110 address>
    11661111
    11671112
    11681113