probinson added a comment. I think there are degrees of compatibility with regard to DWARF, which is inherently supposed to be extensible if the extension can be safely ignored by a consumer. This is the "permissive" rule in the standard.
- A new FORM must *never* be used, because that makes it impossible to interpret the rest of the CU. - A new attribute or tag may be used if it can be safely ignored. - A new constant value for an existing attribute also may be used if it can be safely ignored. For other cases, such as using existing forms/attributes in novel ways, it really depends on how we think (or know) consumers will react to it. DW_AT_high_pc with a constant value is an excellent example; a debugger would not have any obvious reasonable interpretation for that. On the other hand, something like a new language code happens all the time, and there's even a range for user-defined language codes. A debugger must be prepared for unknown values, and an unknown value inside the standard-defined range doesn't seem like a reason to crash, or even bail out. If we implemented a "strict DWARF" mode, then in that mode we should be more careful about this. If you are implementing a DWARF verifier, it would be reasonable to report using language codes outside the range defined by a given DWARF version IMO, but a bug report about that would likely be rejected. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99250/new/ https://reviews.llvm.org/D99250 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
