Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
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||No, C++11 support is not yet supported||--|
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.
How Will Type Info Compression be Beneficial?
DWARF information typically accounts for the majority of an object file’s size. 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
DWARF 4 may be enabled by using the --symdebug:dwarf_version=4 option in 15.12.0 LTS versions of the ARM, MSP430, and C28x compilers. DWARF 4 requires a minimum CCS version of 7.0 and will be enabled by default in new projects in CCS 7.0+.
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 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 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.
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. 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.)
- , The DWARF Debugging Format Standards