Issue 231110.4: DWARF Extension Expiration
| Author: | Ben Woodard |
|---|---|
| Champion: | Mark Wielaard |
| Date submitted: | 2023-11-10 |
| Date revised: | 2024-03-25 |
| Date closed: | |
| Type: | Enhancement |
| Status: | Open |
| DWARF Version: | 6 |
Background
This is an Enhancement issue split off from Issue 231110.1 to expire DWARF extensions when a new DWARF standard version is released.
The DWARF standard has always had the wisdom to acknowledge the need for Vendor Extensibility. Section 1.3.13 describes this policy. For the producers it explicitly reserves some of the valid values for encoding various constructs and promises not to use those values in future versions of the standard. Consumers are given the freedom and expected to skip over data that they do not recognize.
The original intent of these vendor extensions was that they would be a private agreement between a particular producer and a cooperating consumer. However, the range of tools expanded beyond a toolchain provided by a single vendor and so the concept of a private agreement between a specific producer and a cooperating consumer came to be regarded as a registry of vendor extensions that every tool must be aware of for the sake of compatibility.
Because compatibility between tools was prioritized, the extensions in these de facto registries were effectively considered permanent unofficial DWARF encodings. This presumptive permanence is in spite of the fact that in some cases:
-
Producers that made use of these extensions were never implemented or publicly released.
-
Producers that made use of these extensions are so obsolete that not only does the tool chain no longer exist but the hardware that this toolchain was designed for no longer exists except as historical artifacts.
-
Official versions of DWARF encodings that accomplish the same thing have been added to the standard making the vendor extension obsolete.
The accumulation of these vendor extensions over the years has led to
problems with some DWARF constructs where they are running out of
available encodings that do not overlap with the ones used by or
reserved by the standard. In particular the range of vendor
extension encoding is running particularly short in the range of DW_OP
encoding. This has led to several informal proposals within the vendor
community along the lines of an official proposal 230324.1 Expression
Operation Vendor Extensibility Opcode.
The basic idea in most of
these proposals is to extend the range of available vendor extension
encodings. While DWARF expression operations, Section 2.5, has the most
extreme shortage of vendor encodings, other DWARF constructs are also
running out of usable encodings.
Overview
This proposal is an alternative to 230324.1 and similar informal approaches to increase the available encoding space.
It makes explicit that Vendor Extensions can only be interpreted in the context of a particular producer and a DWARF standard version. This way obsolete vendor extensions can be retired when a new version of the standard is released.
A registry would be published on the DWARF standard’s web site so that consumers can easily find it. Each extension would be listed along with the producers that emit it and the range of DWARF standard versions that it applies to. When new DWARF standard versions are released, each extension will be reconsidered to see if it continues to add utility in the context of the new version of the DWARF standard.
Proposed Changes
Section 1.3.13
Replace the following:
Vendors may also use debugging information entries and attributes defined here in new situations. Future versions of this document will not use names or values reserved for vendor specific additions. All names and values not reserved for vendor additions, however, are reserved for future versions of this document
With:
Producers may also use debugging information entries and attributes defined here in new situations. Future versions of this document will not use names or values reserved for these specific additions but the meanings of these encoding may change from DWARF version to version. Therefore the values of these extensions must be interpreted in the context of the DWARF standard versions for which they apply. All names and values not explicitly reserved for producer specific additions, however, are reserved for future versions of this document.
Section 7.1 Vendor Extensibility
Add a new rule 1 at the end of the section:
To ensure that extensions added by one producer may be safely ignored by consumers that do not understand those extensions, the following rules must be followed:
- Producer defined extensions must be evaluated in the context of a DWARF standard version.
And renumber the existing rule numbers to 2..5.
2024-03-25: Split from 231110.1.
