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
98 the LLVM optimizers could optimize debug code just as well as non-debug
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 :ref:`LLVM test suite <test-suite-quickstart>` provides a framework to test
122 .. code-block:: bash
124 % cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level
145 variables, functions, source files, etc) is inserted by the language front-end
151 namespaces, etc: this allows for arbitrary source-language semantics and
152 type-systems to be used, as long as there is a module written for the target
156 assumptions about the source-level language being debugged, though it keeps
163 common to any source-language. :ref:`ccxx_frontend` describes the data layout
164 conventions used by the C and C++ front-ends.
167 <LangRef.html#specialized-metadata>`_, first-class subclasses of ``Metadata``.
172 ----------------------------
180 .. code-block:: llvm
193 .. code-block:: llvm
212 it is non-trivial to model in LLVM, because it has no notion of scoping in this
219 .. code-block:: c
233 .. code-block:: llvm
257 …-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-f…
265 !1 = !DIFile(filename: "/dev/stdin", directory: "/Users/dexonsmith/data/llvm/debug-info")
297 .. code-block:: llvm
306 .. code-block:: llvm
321 .. code-block:: llvm
330 .. code-block:: llvm
344 C/C++ front-end specific debug information
347 The C and C++ front-ends represent information about the program in a format
352 non-dwarf targets to translate it as needed.
359 source-language front-ends, the information used should be documented here.
368 -----------------------------
374 .. code-block:: c++
376 if (DILocation *Loc = I->getDebugLoc()) { // Here I is an LLVM instruction
377 unsigned Line = Loc->getLine();
378 StringRef File = Loc->getFilename();
379 StringRef Dir = Loc->getDirectory();
383 ---------------------------------
387 .. code-block:: c
391 a C/C++ front-end would generate the following descriptors:
393 .. code-block:: llvm
420 directory: "/Users/dexonsmith/data/llvm/debug-info")
447 --------------------------
451 .. code-block:: c
457 a C/C++ front-end would generate the following descriptors:
459 .. code-block:: llvm
480 ----------------------------------------------------------
523 .. code-block:: objc
540 .. code-block:: none
570 auto-synthesized property is the name of the property from which it derives
576 the @interface and @implementation - e.g. to provide a read-only property in
577 the interface,and a read-write interface in the implementation. In that case,
584 .. code-block:: objc
588 .. code-block:: none
598 .. code-block:: objc
602 -(void)myOwnP3Setter:(int)a;
607 -(void)myOwnP3Setter:(int)a{ }
612 .. code-block:: none
634 +-----------------------+--------+
638 +-----------------------+--------+
643 +--------------------------------+--------+-----------+
647 +--------------------------------+--------+-----------+
649 +--------------------------------+--------+-----------+
651 +--------------------------------+--------+-----------+
653 +--------------------------------+--------+-----------+
658 +--------------------------------------+-------+
662 +--------------------------------------+-------+
664 +--------------------------------------+-------+
666 +--------------------------------------+-------+
668 +--------------------------------------+-------+
670 +--------------------------------------+-------+
672 +--------------------------------------+-------+
674 +--------------------------------------+-------+
676 +--------------------------------------+-------+
678 +--------------------------------------+-------+
680 +--------------------------------------+-------+
682 +--------------------------------------+-------+
684 +--------------------------------------+-------+
686 +--------------------------------------+-------+
688 +--------------------------------------+-------+
690 +--------------------------------------+-------+
693 -----------------------
721 its inconsistent and useless public-only name content making it a waste of
744 from disk, and used as is, with little or no up-front parsing. We would also
757 duplicated. We also want to make sure the table is ready to be used as-is by
778 .. code-block:: none
780 .------------.
782 |------------|
784 |------------|
786 `------------'
790 .. code-block:: none
792 .------------.
799 '------------'
806 .. code-block:: none
808 .------------.
813 |------------|
818 |------------|
823 `------------'
843 .. code-block:: none
845 .-------------.
847 |-------------|
849 |-------------|
851 |-------------|
853 |-------------|
855 `-------------'
866 .. code-block:: none
868 .-------------------------.
876 |-------------------------|
878 |-------------------------|
880 |-------------------------|
882 |-------------------------|
884 `-------------------------'
889 .. code-block:: none
891 .------------.
893 |------------|
900 |------------|
916 |------------|
932 |------------|
938 |------------|
940 | 0x00000004 | A 32 bit array count - number of HashData with name "erase"
946 |------------|
948 | 0x00000002 | A 32 bit array count - number of HashData with name "collision"
952 | 0x00000003 | A 32 bit array count - number of HashData with name "dump"
957 |------------|
959 | 0x00000009 | A 32 bit array count - number of HashData with name "main"
970 `------------'
1006 .. code-block:: c
1016 … // Specifically the length of the following HeaderData field - this does not
1030 .. code-block:: c
1049 .. code-block:: c
1077 Atoms, that are contained in the data for each name. First comes the type of
1080 .. code-block:: c
1094 .. code-block:: none
1096 eAtomTypeNULL - a termination atom that specifies the end of the atom list
1097 eAtomTypeDIEOffset - an offset into the .debug_info section for the DWARF DIE for this name
1098 eAtomTypeCUOffset - an offset into the .debug_info section for the CU that contains the DIE
1099 …eAtomTypeDIETag - The DW_TAG_XXX enumeration value so you don't have to parse the DWARF to see…
1100 …eAtomTypeNameFlags - Flags for functions and global variables (isFunction, isInlined, isExternal.…
1101 eAtomTypeTypeFlags - Flags for types (isCXXClass, isObjCClass, ...)
1106 .. code-block:: c
1118 .. code-block:: c
1124 Atoms atoms[atom_count0];
1127 ``HeaderData`` defines the base DIE offset that should be added to any atoms
1130 what is contained in each ``HashData`` object -- ``Atom.form`` tells us how large
1139 .. code-block:: c
1142 HeaderData.atoms[0].type = eAtomTypeDIEOffset;
1143 HeaderData.atoms[0].form = DW_FORM_data4;
1164 .. code-block:: c
1173 .. code-block:: none
1175 .------------.
1183 `------------'
1187 .. code-block:: none
1189 .------------.
1201 `------------'
1222 .. code-block:: c
1267 not be a forward declaration (``DW_AT_declaration`` attribute with a non-zero
1270 .. code-block:: c
1280 .. code-block:: none
1297 standard C++ library that demangles mangled names.
1303 Objective-C Extensions
1307 Objective-C class. The name used in the hash table is the name of the
1308 Objective-C class itself. If the Objective-C class has a category, then an
1311 method "``-[NSString(my_additions) stringWithSpecialString:]``", we would add
1314 track down all Objective-C methods for an Objective-C class when doing
1315 expressions. It is needed because of the dynamic nature of Objective-C where
1316 anyone can add methods to a class. The DWARF for Objective-C methods is also
1319 compile units. Categories can also be defined in different shared libraries.
1321 given the Objective-C class name, or quickly find all methods and class
1323 selector names, it just maps Objective-C class names (or class names +
1327 In the "``.apple_names``" section for Objective-C functions, the full name is
1328 the entire function name with the brackets ("``-[NSString
1332 Mach-O Changes
1335 The sections names for the apple hash tables are for non-mach-o files. For
1336 mach-o files, the sections should be contained in the ``__DWARF`` segment with
1339 * "``.apple_names``" -> "``__apple_names``"
1340 * "``.apple_types``" -> "``__apple_types``"
1341 * "``.apple_namespaces``" -> "``__apple_namespac``" (16 character limit)
1342 * "``.apple_objc``" -> "``__apple_objc``"
1353 -----------------
1361 16-bit record size and a 16-bit record kind.
1380 the source-level type graph may contain cycles through pointer types (consider a
1382 referring to the forward declaration record of user-defined record types. Only
1384 non-forward-declaration type records.
1387 ---------------------
1391 embedded in ``llvm-readobj``.
1395 $ cl -c -Z7 foo.cpp # Use /Z7 to keep types in the object file
1396 $ llvm-readobj -codeview foo.obj
1400 $ clang -g -gcodeview --target=x86_64-windows-msvc foo.cpp -S -emit-llvm
1406 $ llc foo.ll -filetype=obj -o foo.obj
1407 $ llvm-readobj -codeview foo.obj > foo.txt
1409 Use this pattern in lit test cases and FileCheck the output of llvm-readobj