Lines Matching full:dwarf
56 <li><a href="#llvmdwarfextension">LLVM Dwarf Extensions</a>
63 <li><a href="#objcpropertynewattributes">New DWARF Attributes</a></li>
64 <li><a href="#objcpropertynewconstants">New DWARF Constants</a></li>
145 the <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3
167 <p>Currently, debug information is consumed by DwarfDebug to produce dwarf
265 debugging information representation (e.g. DWARF/Stabs/etc). It uses a
320 of tags are loosely bound to the tag values of DWARF information entries.
321 However, that does not restrict the use of the information supplied to DWARF
341 i32, ;; DWARF language identifier (ex. DW_LANG_C89)
357 <p>These descriptors contain a source language ID for the file (we use the DWARF
456 i32, ;; Virtuality, e.g. dwarf::DW_VIRTUALITY__virtual
536 i32 ;; DWARF type encoding
1046 to <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3.0</a> in
1048 support native debuggers by generating standard dwarf information, and
1049 contains enough information for non-dwarf targets to translate it as
1054 representing programs in the same way that DWARF 3 does), or they could
1055 choose to provide completely different forms if they don't fit into the DWARF
1892 consumes information generated by compiler in DWARF format. The format does
1893 not support encoding of Objective C properties. This proposal describes DWARF
1918 To facilitate debugging, these properties we will add a new DWARF TAG into the
1920 given property, and a set of DWARF attributes that provide said description.
1924 If there is a related ivar, there will also be a DWARF property attribute placed
1954 This produces the following DWARF (this is a "pseudo dwarfdump" output):
2041 The DWARF for this would be:
2068 <a name="objcpropertynewtags">New DWARF Tags</a>
2090 <a name="objcpropertynewattributes">New DWARF Attributes</a>
2130 <a name="objcpropertynewconstants">New DWARF Constants</a>
2191 these tables. For example, the DWARF spec states that "In the case of the
2568 <p>DWARF lookup tables can be implemented in a variety of ways and can store
2569 a lot of information for each name. We want to make the DWARF tables
2571 DWARF features that enable efficient data storage to define exactly what kind
2596 eAtomTypeDIEOffset - an offset into the .debug_info section for the DWARF DIE for this name
2598 eAtomTypeDIETag - The DW_TAG_XXX enumeration value so you don't have to parse the DWARF to see what it is
2610 uint16_t form; // DWARF DW_FORM_XXX defines
2614 <p>The "form" type above is from the DWARF specification and defines the
2615 exact encoding of the data for the Atom type. See the DWARF specification for
2650 <p>The KeyType for the DWARF table is a 32 bit string table offset into the
2651 ".debug_str" table. The ".debug_str" is the string table for the DWARF which
2653 help from the compiler, that we reuse the strings between all of the DWARF
2656 DWARF parsing can be made much faster.</p>
2711 different tables. For DWARF, we have 3 tables: ".apple_names", ".apple_types",
2714 <p>".apple_names" sections should contain an entry for each DWARF DIE whose
2739 <p>".apple_types" sections should contain an entry for each DWARF DIE whose
2818 anyone can add methods to a class. The DWARF for Objective-C methods is also
