For things like new tags, attributes, language codes, etc., we have occasionally given out assurances that the assigned numbers were safe to use once discussion was complete and the issue was accepted. In most cases, it's then OK to use these without bumping the DWARF version number, since clients are supposed to be able to tolerate unknown values (although binutils is a notable exception). For DW_LANG_Go, we did in fact issue such an assurance. (I don't even think it was necessary to qualify its use under -gstrict-dwarf, since there's no decent alternative for you to use for Go debug info.)
If DWARF 5 had included nothing new but a few new tags, attributes, and language codes, we would have had no reason to change the version number. New form codes, however, and changes to any of the various compilation unit headers, always require a new DWARF version number. The consumer needs to be able to recognize all form codes or it won't be able to parse the debug info properly, and clearly it needs to understand the structure of the compilation unit headers for each debug section. For a long time, in fact, GCC was generating many tags and attributes from the DWARF-3 spec, while still conforming to the DWARF-2 spec in terms of header structures and form codes. -cary _______________________________________________ Dwarf-Discuss mailing list [email protected] http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
