Lines Matching +full:shared +full:- +full:library +full:- +full:atoms
14 front-ends or dealing directly with the information. Further, this document
18 --------------------------------------------
21 pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
29 * LLVM optimizations should interact in :ref:`well-defined and easily described
33 LLVM-to-LLVM tools should not need to know anything about the semantics of
34 the source-level-language.
36 * Source-level languages are often **widely** different from one another.
37 LLVM should not put any restrictions of the flavor of the source-language,
42 formats. This allows compatibility with traditional machine-code level
47 between LLVM program objects and the source-level objects. The description of
48 the source-level program is maintained in LLVM metadata in an
49 :ref:`implementation-defined format <ccxx_frontend>` (the C/C++ front-end
54 the stored debug information into source-language specific information. As
55 such, a debugger must be aware of the source-language, and is thus tied to a
59 ---------------------------
68 other DWARF-based debuggers. :ref:`CodeViewDebug <codeview>` produces CodeView,
81 -----------------------------------
88 the source-level state of the program**, regardless of which LLVM
99 optimizers could optimize debug code just as well as non-debug code.
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
119 The :doc:`LLVM test-suite <TestSuiteMakefileGuide>` provides a framework to
123 .. code-block:: bash
125 % cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level
146 variables, functions, source files, etc) is inserted by the language front-end
152 namespaces, etc: this allows for arbitrary source-language semantics and
153 type-systems to be used, as long as there is a module written for the target
157 assumptions about the source-level language being debugged, though it keeps
164 common to any source-language. :ref:`ccxx_frontend` describes the data layout
165 conventions used by the C and C++ front-ends.
168 <LangRef.html#specialized-metadata>`_, first-class subclasses of ``Metadata``.
173 ----------------------------
181 .. code-block:: llvm
193 .. code-block:: text
222 .. code-block:: llvm
228 <LangRef.html#dilocalvariable>`_. It is not control-dependent, meaning that if
239 .. code-block:: llvm
262 it is non-trivial to model in LLVM, because it has no notion of scoping in this
269 .. code-block:: c
286 .. code-block:: text
310 …-precise-fpmad"="false" "frame-pointer"="all" "no-infs-fp-math"="false" "no-nans-fp-math"="false" …
318 !1 = !DIFile(filename: "/dev/stdin", directory: "/Users/dexonsmith/data/llvm/debug-info")
350 .. code-block:: llvm
359 .. code-block:: text
374 .. code-block:: llvm
383 .. code-block:: text
414 passes alter or move instructions and blocks -- the developer could observe such
433 .. code-block:: llvm
460 Containing two source-level variables in ``!1`` and ``!3``. The function could,
463 .. code-block:: llvm
480 .. code-block:: llvm
495 the same time as ``!1`` has the constant value zero -- a pair of assignments
500 .. code-block:: llvm
518 observe re-ordering of assignments.
523 LLVM preserves debug information throughout mid-level and backend passes,
524 ultimately producing a mapping between source-level information and
529 represents a source-level assignment of a value to a source variable, the
553 ---------------------------------------------------
562 multiply-and-accumulate) then intermediate Values are lost. To track variable
570 otherwise transformed into a non-register, the variable location becomes
577 After MIR locations are assigned to each variable, machine pseudo-instructions
581 .. code-block:: text
608 .. code-block:: llvm
634 If one compiles this IR with ``llc -o - -start-after=codegen-prepare -stop-after=expand-isel-pseudo…
636 .. code-block:: text
643 %3:gr32 = MOV32r0 implicit-def dead $eflags
644 DBG_VALUE 0, $noreg, !3, !DIExpression(), debug-location !5
650 DBG_VALUE %0, $noreg, !3, !DIExpression(), debug-location !5
651 …DBG_VALUE %2, $noreg, !3, !DIExpression(DW_OP_plus_uconst, 4, DW_OP_stack_value), debug-location !5
652 %4:gr32 = MOV32rm %2, 1, $noreg, 4, $noreg, debug-location !5 :: (load 4 from %ir.addr1)
653 %5:gr64_nosp = MOVSX64rr32 %0, debug-location !5
654 DBG_VALUE $noreg, $noreg, !3, !DIExpression(), debug-location !5
655 %1:gr32 = INC32r %0, implicit-def dead $eflags, debug-location !5
656 DBG_VALUE %1, $noreg, !3, !DIExpression(), debug-location !5
657 …%6:gr32 = ADD32rm %4, %2, 4, killed %5, 0, $noreg, implicit-def dead $eflags :: (load 4 from %ir.a…
658 %7:gr32 = SUB32rr %6, %0, implicit-def $eflags, debug-location !5
659 JB_1 %bb.1, implicit $eflags, debug-location !5
660 JMP_1 %bb.2, debug-location !5
663 %8:gr32 = MOV32r0 implicit-def dead $eflags
664 $eax = COPY %8, debug-location !5
665 RET 0, $eax, debug-location !5
675 (as a 4-byte offset), but the variable location is salvaged by folding
683 ----------------------
686 and the pre-and-post RA machine schedulers. Instruction scheduling can
687 significantly change the nature of the program -- in the (very unlikely) worst
694 of the delay. To illustrate, consider this pseudo-MIR:
696 .. code-block:: text
698 %1:gr32 = MOV32rm %0, 1, $noreg, 4, $noreg, debug-location !5 :: (load 4 from %ir.addr1)
700 %4:gr32 = ADD32rr %3, %2, implicit-def dead $eflags
702 %7:gr32 = SUB32rr %6, %5, implicit-def dead $eflags
707 .. code-block:: text
709 %7:gr32 = SUB32rr %6, %5, implicit-def dead $eflags
710 %1:gr32 = MOV32rm %0, 1, $noreg, 4, $noreg, debug-location !5 :: (load 4 from %ir.addr1)
712 %4:gr32 = ADD32rr %3, %2, implicit-def dead $eflags
717 the DBG_VALUE of virtual register %7 upwards with the SUB32rr, we would re-order
725 .. code-block:: text
728 %4:gr32 = ADD32rr %3, %2, implicit-def dead $eflags
730 %7:gr32 = SUB32rr %6, %5, implicit-def dead $eflags
732 %1:gr32 = MOV32rm %0, 1, $noreg, 4, $noreg, debug-location !5 :: (load 4 from %ir.addr1)
745 ---------------------------------------------
751 VirtRegRewriter pass re-inserts DBG_VALUE instructions in their original
758 -----------------------------------------------
767 corresponding to a source-level assignment where the variable may change value,
774 .. code-block:: text
809 that it uses use-def chains to identify control flow merges and insert phi
841 C/C++ front-end specific debug information
844 The C and C++ front-ends represent information about the program in a
848 information, and contains enough information for non-dwarf targets to
856 source-language front-ends, the information used should be documented here.
865 -----------------------------
871 .. code-block:: c++
873 if (DILocation *Loc = I->getDebugLoc()) { // Here I is an LLVM instruction
874 unsigned Line = Loc->getLine();
875 StringRef File = Loc->getFilename();
876 StringRef Dir = Loc->getDirectory();
877 bool ImplicitCode = Loc->isImplicitCode();
881 added by the front-end but doesn't correspond to source code written by the user. For example
883 .. code-block:: c++
895 ---------------------------------
899 .. code-block:: c
903 a C/C++ front-end would generate the following descriptors:
905 .. code-block:: text
934 directory: "/Users/dexonsmith/data/llvm/debug-info")
964 --------------------------
968 .. code-block:: c
974 a C/C++ front-end would generate the following descriptors:
976 .. code-block:: text
997 ----------------------------------------
1003 .. code-block:: c
1012 .. code-block:: text
1018 .. code-block:: text
1030 ----------------------------
1032 … LLVM can generate (or omit) the appropriate DWARF attributes for the prefix-specs of ELEMENTAL, P…
1034 .. code-block:: fortran
1038 a Fortran front-end would generate the following descriptors:
1040 .. code-block:: text
1049 .. code-block:: text
1059 .. code-block:: fortran
1063 a Fortran front-end would generate the following descriptors:
1065 .. code-block:: text
1072 .. code-block:: text
1087 ----------------------------------------------------------
1130 .. code-block:: objc
1147 .. code-block:: none
1177 auto-synthesized property is the name of the property from which it derives
1183 the @interface and @implementation - e.g. to provide a read-only property in
1184 the interface, and a read-write interface in the implementation. In that case,
1191 .. code-block:: objc
1195 .. code-block:: none
1205 .. code-block:: objc
1209 -(void)myOwnP3Setter:(int)a;
1214 -(void)myOwnP3Setter:(int)a{ }
1219 .. code-block:: none
1241 +-----------------------+--------+
1245 +-----------------------+--------+
1250 +--------------------------------+--------+-----------+
1254 +--------------------------------+--------+-----------+
1256 +--------------------------------+--------+-----------+
1258 +--------------------------------+--------+-----------+
1260 +--------------------------------+--------+-----------+
1265 +--------------------------------------+-------+
1269 +--------------------------------------+-------+
1271 +--------------------------------------+-------+
1273 +--------------------------------------+-------+
1275 +--------------------------------------+-------+
1277 +--------------------------------------+-------+
1279 +--------------------------------------+-------+
1281 +--------------------------------------+-------+
1283 +--------------------------------------+-------+
1285 +--------------------------------------+-------+
1287 +--------------------------------------+-------+
1289 +--------------------------------------+-------+
1291 +--------------------------------------+-------+
1293 +--------------------------------------+-------+
1295 +--------------------------------------+-------+
1297 +--------------------------------------+-------+
1300 -----------------------
1328 its inconsistent and useless public-only name content making it a waste of
1351 from disk, and used as is, with little or no up-front parsing. We would also
1364 duplicated. We also want to make sure the table is ready to be used as-is by
1385 .. code-block:: none
1387 .------------.
1389 |------------|
1391 |------------|
1393 `------------'
1397 .. code-block:: none
1399 .------------.
1406 '------------'
1413 .. code-block:: none
1415 .------------.
1420 |------------|
1425 |------------|
1430 `------------'
1434 if we were to lookup "``printf``" in the table above, we would make a 32-bit
1450 .. code-block:: none
1452 .-------------.
1454 |-------------|
1456 |-------------|
1458 |-------------|
1460 |-------------|
1462 `-------------'
1473 .. code-block:: none
1475 .-------------------------.
1483 |-------------------------|
1485 |-------------------------|
1487 |-------------------------|
1489 |-------------------------|
1491 `-------------------------'
1496 .. code-block:: none
1498 .------------.
1500 |------------|
1507 |------------|
1523 |------------|
1539 |------------|
1545 |------------|
1547 | 0x00000004 | A 32 bit array count - number of HashData with name "erase"
1553 |------------|
1555 | 0x00000002 | A 32 bit array count - number of HashData with name "collision"
1559 | 0x00000003 | A 32 bit array count - number of HashData with name "dump"
1564 |------------|
1566 | 0x00000009 | A 32 bit array count - number of HashData with name "main"
1577 `------------'
1613 .. code-block:: c
1623 … // Specifically the length of the following HeaderData field - this does not
1637 .. code-block:: c
1656 .. code-block:: c
1684 Atoms, that are contained in the data for each name. First comes the type of
1687 .. code-block:: c
1701 .. code-block:: none
1703 eAtomTypeNULL - a termination atom that specifies the end of the atom list
1704 eAtomTypeDIEOffset - an offset into the .debug_info section for the DWARF DIE for this name
1705 eAtomTypeCUOffset - an offset into the .debug_info section for the CU that contains the DIE
1706 …eAtomTypeDIETag - The DW_TAG_XXX enumeration value so you don't have to parse the DWARF to see…
1707 …eAtomTypeNameFlags - Flags for functions and global variables (isFunction, isInlined, isExternal.…
1708 eAtomTypeTypeFlags - Flags for types (isCXXClass, isObjCClass, ...)
1713 .. code-block:: c
1725 .. code-block:: c
1731 Atoms atoms[atom_count0];
1734 ``HeaderData`` defines the base DIE offset that should be added to any atoms
1737 what is contained in each ``HashData`` object -- ``Atom.form`` tells us how large
1746 .. code-block:: c
1749 HeaderData.atoms[0].type = eAtomTypeDIEOffset;
1750 HeaderData.atoms[0].form = DW_FORM_data4;
1771 .. code-block:: c
1780 .. code-block:: none
1782 .------------.
1790 `------------'
1794 .. code-block:: none
1796 .------------.
1808 `------------'
1829 .. code-block:: c
1875 not be a forward declaration (``DW_AT_declaration`` attribute with a non-zero
1878 .. code-block:: c
1888 .. code-block:: none
1905 standard C++ library that demangles mangled names.
1911 Objective-C Extensions
1915 Objective-C class. The name used in the hash table is the name of the
1916 Objective-C class itself. If the Objective-C class has a category, then an
1919 method "``-[NSString(my_additions) stringWithSpecialString:]``", we would add
1922 track down all Objective-C methods for an Objective-C class when doing
1923 expressions. It is needed because of the dynamic nature of Objective-C where
1924 anyone can add methods to a class. The DWARF for Objective-C methods is also
1927 compile units. Categories can also be defined in different shared libraries.
1929 given the Objective-C class name, or quickly find all methods and class
1931 selector names, it just maps Objective-C class names (or class names +
1935 In the "``.apple_names``" section for Objective-C functions, the full name is
1936 the entire function name with the brackets ("``-[NSString
1940 Mach-O Changes
1943 The sections names for the apple hash tables are for non-mach-o files. For
1944 mach-o files, the sections should be contained in the ``__DWARF`` segment with
1947 * "``.apple_names``" -> "``__apple_names``"
1948 * "``.apple_types``" -> "``__apple_types``"
1949 * "``.apple_namespaces``" -> "``__apple_namespac``" (16 character limit)
1950 * "``.apple_objc``" -> "``__apple_objc``"
1961 -----------------
1969 16-bit record size and a 16-bit record kind.
1988 the source-level type graph may contain cycles through pointer types (consider a
1990 referring to the forward declaration record of user-defined record types. Only
1992 non-forward-declaration type records.
1995 ---------------------
1999 embedded in ``llvm-readobj``.
2003 $ cl -c -Z7 foo.cpp # Use /Z7 to keep types in the object file
2004 $ llvm-readobj --codeview foo.obj
2008 $ clang -g -gcodeview --target=x86_64-windows-msvc foo.cpp -S -emit-llvm
2014 $ llc foo.ll -filetype=obj -o foo.obj
2015 $ llvm-readobj --codeview foo.obj > foo.txt
2017 Use this pattern in lit test cases and FileCheck the output of llvm-readobj