Source Level Debugging with LLVM
================================
-.. sectionauthor:: Chris Lattner <sabre@nondot.org> and Jim Laskey <jlaskey@mac.com>
-
.. contents::
:local:
Compile unit descriptors provide the root context for objects declared in a
specific compilation unit. File descriptors are defined using this context.
-These descriptors are collected by a named metadata ``!llvm.dbg.cu``. Compile
-unit descriptor keeps track of subprograms, global variables and type
-information.
+These descriptors are collected by a named metadata ``!llvm.dbg.cu``. They
+keep track of subprograms, global variables and type information.
.. _format_files:
{}* ;; Reference to the global variable
}
-These descriptors provide debug information about globals variables. The
+These descriptors provide debug information about globals variables. They
provide details such as name, type and where the variable is defined. All
global variables are collected inside the named metadata ``!llvm.dbg.cu``.
metadata, ;; Reference to type descriptor
i1, ;; True if the global is local to compile unit (static)
i1, ;; True if the global is defined in the compile unit (not extern)
- i32, ;; Line number where the scope of the subprogram begins
i32, ;; Virtuality, e.g. dwarf::DW_VIRTUALITY__virtual
i32, ;; Index into a virtual function
metadata, ;; indicates which base type contains the vtable pointer for the
Function * , ;; Pointer to LLVM function
metadata, ;; Lists function template parameters
metadata, ;; Function declaration descriptor
- metadata ;; List of function variables
+ metadata, ;; List of function variables
+ i32 ;; Line number where the scope of the subprogram begins
}
These descriptors provide debug information about functions, methods and
i32, ;; Flags to encode attributes, e.g. private
metadata, ;; Reference to type derived from
metadata, ;; (optional) Name of the Objective C property associated with
- ;; Objective-C an ivar
+ ;; Objective-C an ivar, or the type of which this
+ ;; pointer-to-member is pointing to members of.
metadata, ;; (optional) Name of the Objective C property getter selector.
metadata, ;; (optional) Name of the Objective C property setter selector.
i32 ;; (optional) Objective C property attributes.
.. code-block:: llvm
- DW_TAG_formal_parameter = 5
- DW_TAG_member = 13
- DW_TAG_pointer_type = 15
- DW_TAG_reference_type = 16
- DW_TAG_typedef = 22
- DW_TAG_const_type = 38
- DW_TAG_volatile_type = 53
- DW_TAG_restrict_type = 55
+ DW_TAG_formal_parameter = 5
+ DW_TAG_member = 13
+ DW_TAG_pointer_type = 15
+ DW_TAG_reference_type = 16
+ DW_TAG_typedef = 22
+ DW_TAG_ptr_to_member_type = 31
+ DW_TAG_const_type = 38
+ DW_TAG_volatile_type = 53
+ DW_TAG_restrict_type = 55
``DW_TAG_member`` is used to define a member of a :ref:`composite type
<format_composite_type>` or :ref:`subprogram <format_subprograms>`. The type
DW_TAG_enumeration_type = 4
DW_TAG_structure_type = 19
DW_TAG_union_type = 23
- DW_TAG_vector_type = 259
DW_TAG_subroutine_type = 21
DW_TAG_inheritance = 28
The vector flag indicates that an array type is a native packed vector.
-The members of array types (tag = ``DW_TAG_array_type``) or vector types (tag =
-``DW_TAG_vector_type``) are :ref:`subrange descriptors <format_subrange>`, each
+The members of array types (tag = ``DW_TAG_array_type``) are
+:ref:`subrange descriptors <format_subrange>`, each
representing the range of subscripts at that level of indexing.
The members of enumeration types (tag = ``DW_TAG_enumeration_type``) are
DW_TAG_auto_variable = 256
DW_TAG_arg_variable = 257
- DW_TAG_return_variable = 258
An auto variable is any variable declared in the body of the function. An
argument variable is any variable that appears as a formal argument to the
-function. A return variable is used to track the result of a function and has
-no source correspondent.
+function.
The context is either the subprogram or block where the variable is defined.
Name the source variable name. Context and line indicate where the variable
| HEADER.header_data_len | uint32_t
| HEADER_DATA | HeaderData
|-------------------------|
- | BUCKETS | uint32_t[bucket_count] // 32 bit hash indexes
+ | BUCKETS | uint32_t[n_buckets] // 32 bit hash indexes
|-------------------------|
- | HASHES | uint32_t[hashes_count] // 32 bit hash values
+ | HASHES | uint32_t[n_hashes] // 32 bit hash values
|-------------------------|
- | OFFSETS | uint32_t[hashes_count] // 32 bit offsets to hash value data
+ | OFFSETS | uint32_t[n_hashes] // 32 bit offsets to hash value data
|-------------------------|
| ALL HASH DATA |
`-------------------------'
HeaderData.atoms[0].form = DW_FORM_data4;
This defines the contents to be the DIE offset (eAtomTypeDIEOffset) that is
- encoded as a 32 bit value (DW_FORM_data4). This allows a single name to have
- multiple matching DIEs in a single file, which could come up with an inlined
- function for instance. Future tables could include more information about the
- DIE such as flags indicating if the DIE is a function, method, block,
- or inlined.
+encoded as a 32 bit value (DW_FORM_data4). This allows a single name to have
+multiple matching DIEs in a single file, which could come up with an inlined
+function for instance. Future tables could include more information about the
+DIE such as flags indicating if the DIE is a function, method, block,
+or inlined.
The KeyType for the DWARF table is a 32 bit string table offset into the
- ".debug_str" table. The ".debug_str" is the string table for the DWARF which
- may already contain copies of all of the strings. This helps make sure, with
- help from the compiler, that we reuse the strings between all of the DWARF
- sections and keeps the hash table size down. Another benefit to having the
- compiler generate all strings as DW_FORM_strp in the debug info, is that
- DWARF parsing can be made much faster.
+".debug_str" table. The ".debug_str" is the string table for the DWARF which
+may already contain copies of all of the strings. This helps make sure, with
+help from the compiler, that we reuse the strings between all of the DWARF
+sections and keeps the hash table size down. Another benefit to having the
+compiler generate all strings as DW_FORM_strp in the debug info, is that
+DWARF parsing can be made much faster.
After a lookup is made, we get an offset into the hash data. The hash data
- needs to be able to deal with 32 bit hash collisions, so the chunk of data
- at the offset in the hash data consists of a triple:
+needs to be able to deal with 32 bit hash collisions, so the chunk of data
+at the offset in the hash data consists of a triple:
.. code-block:: c
HashData[hash_data_count]
If "str_offset" is zero, then the bucket contents are done. 99.9% of the
- hash data chunks contain a single item (no 32 bit hash collision):
+hash data chunks contain a single item (no 32 bit hash collision):
.. code-block:: none
projects / oota-llvm.git / blobdiff