What is DWARF 4?

DWARF 4 is the 4th revision of the DWARF Debugging Format. 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 the following:

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.

COFF

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 smaller.

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 long.

ELF

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 COMDAT merging.

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.)