DWARF Standard


HOME
SPECIFICATIONS
FAQ
ISSUES



130526.1 Eric Christopher Type Unit Merge Enhancement Accepted with modifications Eric Christopher


Introduction
----------------

The type unit DIEs from DWARF4 were a great addition that allowed easy
merging and locating of types in the type section. However, type units
have made accessing data in a unified manner more difficult. There are
now two sections with offsets, or multiple types of data (type unit,
data4/8, ref4/8, sec_offset) that must be used to access an individual
DIE in the debug info. This isn't optimal for space or speed of access
as either we need to have multiple abbreviations or use flags to
distinguish based on the type of data we expect to have rather than
going straight to the DIE we're looking for.


Overview
----------------

This proposal merges the type units into the .debug_info section and
extends the existing headers to distinguish between the two as we
iterate through the units in the section.


Changes to the DWARF Specification
-------------------------------------------------

Remove references to .debug_types from the following locations:

Section 2.1, last paragraph.
Section 2.5.1.5, bullet item 4.
Section 6, first paragraph.
Section 6.1.2, bullet item 3.
Section 7.2.2, first paragraph.
Section 7.4, bullet item 2.
Section 7.5.3, second paragraph.
Section 7.25, first paragraph.
Appendix B, Figure 43.
Appendix F, second paragraph, Figure 97, and third bullet item under Notes.

Section 7.5 (Format of Debugging Information)

Replace with the following:

For each compilation unit compiled with a DWARF producer, a
contribution is made to the .debug_info section of the object file.
Each such contribution consists of a compilation unit header (see
Section 7.5.1.1) followed by a single DW_TAG_compile_unit or
DW_TAG_partial_unit debugging information entry, together with its
children.

For each type defined in a compilation unit a separate contribution
may be made to the .debug_info section instead of a standard
contribution (see Section 2). Each separate contribution consists of a
type unit header (see Section 7.5.1.2) followed by a DW_TAG_type_unit
entry, together with its children.

Each debugging information entry begins with a code that represents an
entry in a separate abbreviations table. This code is followed
directly by a series of attribute values.

The appropriate entry in the abbreviations table guides the
interpretation of the information contained directly in the
.debug_info section.

Multiple debugging information entries may share the same abbreviation
table entry. Each compilation unit is associated with a particular
abbreviation table, but multiple compilation units may share the same
table.


Section 7.5.1.1 (Compilation Unit Header)

In bullet item 2, change "The value in this field is 4" to "The value
in this field is 5."

Between bullet items 2 and 3, add the following new field:

3.    unit_type (ubyte)
The value 1, identifying this unit as a compilation unit.

and renumber the following accordingly.

Section 7.5.1.2 (Type Unit Header)

In the first paragraph, replace "within the .debug_types section" with
"within the .debug_types or .debug_info sections"

In bullet item 2, change "The value in this field is 4" to "The value
in this field is 5."

Between bullet items 2 and 3, add the following new field:

3.    unit_type (ubyte)
The value 2, identifying this unit as a type unit.

(Renumber the following bullets as necessary.)


Appendix E

Replace the first three paragraphs of Section E.2 (Using Type Units)
with the following:

A large portion of debug information is type information, and in a
typical compilation environment, many types are duplicated many times.
One method of controlling the amount of duplication is separating each
type into a separate COMDAT section and arranging for the linker to
recognize and eliminate duplicates at the individual type level.

Using this technique, each substantial type definition is placed in
its own individual section, while the remainder of the DWARF
information (non-type information, incomplete type declarations, and
definitions of trivial types) is placed in the usual debug information
section. In a typical implementation, the relocatable object file may
contain one of each of these debug sections:

 .debug_abbrev
 .debug_info
 .debug_line

and any number of additional COMDAT .debug_info sections containing type units.

As discussed in the previous section (Section E.1), many linkers today
support the concept of a COMDAT group or linkonce section. The general
idea is that a "key" can be attached to a section or a group of
sections, and the linker will include only one copy of a section group
(or individual section) for any given key. For type unit sections, the
key is the type signature formed from the algorithm given in Section
7.27.

--

Revised 1/20/2014.
Accepted 2/25/2014 with following modifications:
   Values for unit_type:
   DW_UT_compile      1     ! For DW_TAG_compile_unit
   DW_UT_type         2     ! For DW_RAG_type_unit
   DW_UT_partial code 3     ! For DW_TAG_partial_unit


All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.