# What is DWARF 4?
DWARF 4 is the 4th revision of the
[DWARF Debugging Format](http://dwarfstd.org/). The new version of the
standard provides many fixes to the format of information from DWARF version
3, adds support for VLIW architectures, adds support for compression of type
information with a new section, and adds support for C++11.
# What Does DWARF 4 Mode Do in TI Compilers?
Of the above general areas of change to the standard, TI compilers implement
Feature | Implemented? | Impacts CCS Users?
Information Format Fixes | Yes | No
Support for VLIW Architectures | No | --
Type Info Compression | Yes | Yes
C++11 Support | Yes | Yes
Changes to the format of information only impact DWARF consumers, such as the
CCS debugger. Type information compression is also a change in the
representation of information, but it may benefit large projects as well.
# Why Type Info Compression is Helpful
DWARF information typically accounts for a large part of an object file. The
largest share of this space is often type information. In a large project with
many object files, type information can take up a large amount of disk space
and slow the compilation process.
# How Do I Use DWARF 4?
DWARF 4 may be enabled by using the --symdebug:dwarf_version=4 option in
recent versions of TI compilers. DWARF 4 requires a minimum CCS version of
7.0. It will be enabled by default in later versions of CCS.
# Potential Issues
Earlier versions of CCS do not support the .debug_types section and may cause
a "DWARF information is corrupted" error. In general, if you experience any
difficulties with DWARF 4, it may be disabled by re-compiling all the source
files with --symdebug:dwarf_version=3.
# A Brief History of Duplicate Type Elimination
The issue of duplicate type information elimination has been approached for
COFF object files and ELF object files in different ways. Each method has its
own benefits and drawbacks.
The parser does not emit information for types that were not used. Each object
file gets a single .debug_info section which contains all type information
(among other things). At link time, type information is read in from the
output file and duplicate types are removed.
**PROS:** Unused type information is not emitted. This keeps object files
**CONS:** Duplicate type information identification & elimination happens at
link time. This includes reading in the type information, walking type trees,
generating hashes, etc. This is very costly and can cause link times to be
The parser emits type information for all encountered types -- even types that
were not used. The assembler generates multiple COMDAT type-only .debug_info
sections; one per file. Duplicate COMDAT sections are automatically eliminated
by the linker. (This is why the parser emitted all type information -- to
ensure for header files that the type info COMDAT sections look the same and
can be eliminated.)
**PROS:** No complex type merging takes place at link time; it is handled by
**CONS:** Unused type information is emitted; for some projects that include
long, complex headers repeatedly, this can cause type information to take a
large amount of space in object files.
## DWARF 4 Type Units
The introduction of DWARF 4 brings the idea of a "type unit" with it. Type
units are placed in their own section, .debug_types. Each type unit is given a
unique signature to identify it. By adding a pre-computed type signature to
type information, the best of COFF/ELF methods may be achieved:
- Unused type information is not emitted (benefit of COFF merging)
- Object files are small (benefit of COFF merging)
- No complex type merging takes place at link time, which keeps the link fast
(benefit of ELF merging; type signatures are already known so types are
eliminated similarly to COMDAT.)