DWARF Debugging Standard Wiki

Some proposals for Dwarf 4 require a change in the version number for the specific section they affect because the modified section cannot be read at all unless the new changes are taken into account.

Based on past experience I expect vendors to upgrade like this:

1) Compatible changes will be incorporated in an ad-hoc way. New attributes and tags can be adopted without breaking any consumers.

2) Incompatible changes should not be adopted unless (a) there is a serious problem that needs to be addressed which cannot be put off, or (b) enough time has passed that consumers have all had a chance to implement the extensions, if they care to.

It might help to take the following actions:

1) Explicitly call out which changes in Dwarf 4 are compatible with dwarf 3. These would be suitable for including in a \“dwarf 3+\” compiler\’s output. This should be done be adding a general description at the start of a chapter called \“dwarf 3 to 4 migration\”. It\’s NOT necessary to scatter words on all the new attributes like \“this is a forward compatible change from dwarf 3 to dwarf 4\”.

2) For incompatible changes, in this new section, give guidance on when/why/where such changes should be used. Until consumers have been ported, there\’s no need to adopt the incompatible changes unless an implementation is faced with the specific bugs or problems that are addressed by the incompatible change.

3) Continue to document both version N and version N+1 formats of section data in the standard. Explain carefully that version N will not be officially deprecated until Dwarf 5.

---

incompat changes:

• new form for section offsets
• add address-size segment-size to CIE header (for DW_OP_addr eg)

dwarfstd.org is supported by Sourceware. Contributions are welcome. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2007-2022 by DWARF Standards Committee.