Lines Matching refs:information
11 This document is the central repository for all information pertaining to debug
12 information in LLVM. It describes the :ref:`actual format that the LLVM debug
13 information takes <format>`, which is useful for those interested in creating
14 front-ends or dealing directly with the information. Further, this document
15 provides specific examples of what debug information for C/C++ looks like.
17 Philosophy behind LLVM debugging information
20 The idea of the LLVM debugging information is to capture how the important
25 * Debugging information should have very little impact on the rest of the
27 be modified because of debugging information.
30 ways <intro_debugopt>` with the debugging information.
38 and the debugging information should work with any language.
54 the stored debug information into source-language specific information. As
58 Debug information consumers
61 The role of debug information is to provide meta information normally stripped
62 away during the compilation process. This meta information provides an LLVM
70 as Visual Studio and WinDBG. LLVM's debug information format is mostly derived
74 It would also be reasonable to use debug information to feed profiling tools
80 Debug information and optimizations
83 An extremely high priority of LLVM debugging information is to make it interact
85 information provides the following guarantees:
87 * LLVM debug information **always provides information to accurately read
96 information, allowing them to update the debugging information as they
100 * LLVM debug information does not prevent optimizations from
104 * LLVM debug information is automatically optimized along with the rest of
106 information is automatically merged by the linker, and unused information
109 Basically, the debug information allows you to compile a program with
110 "``-O0 -g``" and get full debug information, allowing you to arbitrarily modify
112 "``-O3 -g``" gives you full debug information that is always available and
119 optimizer's handling of debugging information. It can be run like this:
126 This will test impact of debugging information on optimization passes. If
127 debugging information influences optimization passes then it will be reported
128 as a failure. See :doc:`TestingGuide` for more information on LLVM test
133 Debugging information format
136 LLVM debugging information has been carefully designed to make it possible for
137 the optimizer to optimize the program and debugging information without
138 necessarily having to know anything about debugging information. In
139 particular, the use of metadata avoids duplicated debugging information from
141 debugging information for a function if it decides to delete the function.
143 To do this, most of the debugging information (descriptors for types,
147 Debug information is designed to be agnostic about the target debugger and
148 debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic
149 pass to decode the information that represents variables, types, functions,
152 debugger to interpret the information.
159 debugger to form stack traces, show information about local variables, etc.
165 Debug information descriptors are `specialized metadata nodes
183 This intrinsic provides information about a local element (e.g., variable).
241 This intrinsic provides information when a user source variable is set to a new
264 llvm instructions to encode line number and scoping information. Consider the
343 information. In particular, it shows how the ``llvm.dbg.declare`` intrinsic and
344 location information, which are attached to an instruction, are applied
353 The first intrinsic ``%llvm.dbg.declare`` encodes debugging information for the
355 scope information for the variable ``X``.
364 Here ``!14`` is metadata providing `location information
367 information attached to the intrinsics indicates that the variable ``X`` is
377 The third intrinsic ``%llvm.dbg.declare`` encodes debugging information for
379 scope information for the variable ``Z``.
390 The scope information attached with each instruction provides a straightforward
395 C/C++ front-end specific debug information
398 The C and C++ front-ends represent information about the program in a format
400 <http://www.eagercon.com/dwarf/dwarf3std.htm>`_ in terms of information
402 generating standard dwarf information, and contains enough information for
409 As support for debugging information gets added to the various LLVM
410 source-language front-ends, the information used should be documented here.
413 information that would best describe those constructs. The canonical
418 C/C++ source file information
422 instruction. One can extract line number information encoded in LLVM IR using
433 C/C++ global variable information
502 C/C++ function information
532 Debugging information format
548 information generated by compiler in DWARF format. The format does not support
766 given by the ``DW_AT_name attribute`` of the referenced debugging information
1125 of information for each name. We want to make the DWARF tables extensible and
1131 We might want to store an offset to all of the debug information entries (DIEs)
1204 function for instance. Future tables could include more information about the
1413 majority of debug information tends to be type information. Therefore, the
1414 overriding design constraint of CodeView is the separation of type information
1415 from other "symbol" information so that type information can be efficiently
1416 merged across translation units. Both type information and symbol information is
1420 Type information is usually stored in the ``.debug$T`` section of the object
1426 to the PDB. When using PDBs, symbol information appears to remain in the object
1487 The first applies synthetic debug information to every instruction of the module,