After several years a new DWARF debugging standard, DWARF5, has been released that incorporates various GNU extensions that allow to better express how to map various binary constructs created by optimizing compilers back to the original source code while reducing the size of the debugging information. This results in more expressive debuginfo, but also introduces more complexity that DWARF consumers need to deal with.
We will go over the existing GNU Extensions to DWARF, how they were adopted by DWARF5, and describe how debug consumers can take advantage of them. To reduce space a lot of different strategies are being used. Separate .debug files, .gnu_debuglink, build-ids, compressed ELF sections, debug types in ELF COMDAT sections, the Dwarf Compressor DWZ .multi files, DWARF Supplementary Object Files, GNU Debug Fission, split-dwarf .dwo files, DWARF Package Files .dwp files. The basic structure of describing a program with a tree of Debug Information Entries (DIEs) with attributes per compile unit augmented with some auxiliary data structures to map to source files, describe macros used in the source and get call frame information hasn't fundementally changed between DWARF version 2 and version 5. But the hierarchy of the representation and where the bits are stored has become much more complex. It is no longer possible to just see the DWARF descriptions as a fancy symbol table which can be simply indexed through some offsets. It has also become much more expressive than that.
Speakers: Mark Wielaard