• Home
  • Raw
  • Download

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
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 debugging information, allowing them to update the debugging information
101 * LLVM debug information does not prevent optimizations from
105 * LLVM debug information is automatically optimized along with the rest of
107 information is automatically merged by the linker, and unused information
110 Basically, the debug information allows you to compile a program with
111 "``-O0 -g``" and get full debug information, allowing you to arbitrarily modify
113 "``-O3 -g``" gives you full debug information that is always available and
120 optimizer's handling of debugging information. It can be run like this:
127 This will test impact of debugging information on optimization passes. If
128 debugging information influences optimization passes then it will be reported
129 as a failure. See :doc:`TestingGuide` for more information on LLVM test
134 Debugging information format
137 LLVM debugging information has been carefully designed to make it possible for
138 the optimizer to optimize the program and debugging information without
139 necessarily having to know anything about debugging information. In
140 particular, the use of metadata avoids duplicated debugging information from
142 debugging information for a function if it decides to delete the function.
144 To do this, most of the debugging information (descriptors for types,
148 Debug information is designed to be agnostic about the target debugger and
149 debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic
150 pass to decode the information that represents variables, types, functions,
153 debugger to interpret the information.
160 debugger to form stack traces, show information about local variables, etc.
166 Debug information descriptors are `specialized metadata nodes
175 provide debug information at various points in generated code.
184 This intrinsic provides information about a local element (e.g., variable).
197 This intrinsic provides information when a user source variable is set to a new
216 llvm instructions to encode line number and scoping information. Consider the
292 information. In particular, it shows how the ``llvm.dbg.declare`` intrinsic and
293 location information, which are attached to an instruction, are applied
302 The first intrinsic ``%llvm.dbg.declare`` encodes debugging information for the
304 scope information for the variable ``X``.
313 Here ``!14`` is metadata providing `location information
316 information attached to the intrinsics indicates that the variable ``X`` is
326 The third intrinsic ``%llvm.dbg.declare`` encodes debugging information for
328 scope information for the variable ``Z``.
339 The scope information attached with each instruction provides a straightforward
344 C/C++ front-end specific debug information
347 The C and C++ front-ends represent information about the program in a format
349 <http://www.eagercon.com/dwarf/dwarf3std.htm>`_ in terms of information
351 generating standard dwarf information, and contains enough information for
358 As support for debugging information gets added to the various LLVM
359 source-language front-ends, the information used should be documented here.
362 information that would best describe those constructs. The canonical
367 C/C++ source file information
371 instruction. One can extract line number information encoded in LLVM IR using
382 C/C++ global variable information
446 C/C++ function information
476 Debugging information format
492 information generated by compiler in DWARF format. The format does not support
710 given by the ``DW_AT_name attribute`` of the referenced debugging information
1069 of information for each name. We want to make the DWARF tables extensible and
1075 We might want to store an offset to all of the debug information entries (DIEs)
1148 function for instance. Future tables could include more information about the
1356 majority of debug information tends to be type information. Therefore, the
1357 overriding design constraint of CodeView is the separation of type information
1358 from other "symbol" information so that type information can be efficiently
1359 merged across translation units. Both type information and symbol information is
1363 Type information is usually stored in the ``.debug$T`` section of the object
1369 to the PDB. When using PDBs, symbol information appears to remain in the object