Issue 231110.2: Change Vendor to Producer for DWARF extensions
| Author: | Ben Woodard |
|---|---|
| Champion: | Mark Wielaard |
| Date submitted: | 2023-11-10 |
| Date revised: | 2024-03-25 |
| Date closed: | |
| Type: | Editorial |
| Status: | Open |
| DWARF Version: | 6 |
Background
This is an Editorial issue split off from Issue 231110.1 to change the word "vendor" to the word "producer".
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.
Tools chains are no longer developed by a close knit group of developers who all work for a single vendor. Tools are now developed by diverse distributed teams and users need and rightly expect interoperability.
Because the bulk of tool development is no longer done by vendors who build a vertically integrated tool chain but rather is done by looser confederation of projects that need to cooperate to achieve compatibility, the term “vendor” is replaced with more generic terms when referring to these extensions.
Proposed Changes
Section 1.3.13
Section 1.3.13 currently named “Vendor Extensibility” shall be renamed to “Extensibility” to reflect the fact that cooperating tools using these extensions are no longer being developed by vendors who control the entire tool chain. Likewise the following paragraphs should change to:
This document does not attempt to cover all interesting languages or even to cover all of the possible debugging information needs for its primary target languages. Therefore, the document provides tool developers a way to define their own debugging information tags, attributes, base type encodings, location operations, language names, calling conventions and call frame instructions by reserving a subset of the valid values for these constructs for tool developer specific additions and defining related naming conventions. 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. All names and values not reserved for producer additions, however, are reserved for future versions of this document.
Where this specification provides a means for describing the source language, implementers are expected to adhere to that specification. For language features that are not supported, implementers may use existing attributes in novel ways or add producer-defined attributes.
(Where terms replace the word vendor in the original text.)
Section 6.1.1.2 Structure of the Name Index
The paragraph:
A producer may define additional vendor-specific attributes, and a consumer will be able to ignore and skip over any attributes it is not prepared to handle.
is replaced by:
A producer may define additional producer-specific attributes, and a consumer should be able to ignore and skip over any attributes it is not prepared to handle.
Section 6.2.4 The Line Number Program Header
In the definition of “opcode base”, the phrase “vendor-specific extensions” should be replaced with “producer-specific extensions” in all three places where it is used.
Section 6.2.4.2 Vendor-defined Content Descriptions
The name of the section should be changed to “Producer-defined Content Descriptions” and the first word of the first sentence should also be changed to match.
The non-normative text following the section should be changed to:
If a consumer encounters a producer-defined content type that it does not understand, it should skip the content data as though it were not present.
Section 6.3.1 Macro Information Header
In the second paragraph of item 4 the phrase “Vendor extension entry opcodes” should be replaced with “Producer specific entry opcodes”.
Section 7.1 Vendor Extensibility
The name of the section should be changed from “Vendor Extensibility” to “Extensibility”.
Throughout section 7.1 the phrase “vendor specific” should be replaced with “producer specific”.
In the second paragraph, the sentence beginning with “Vendors may use values” should be replaced with “Producers may use values”.
The paragrapha at the end of the section should be replaced with:
Producer defined tags, attributes, base type encodings, location atoms, language names, line number actions, calling conventions and call frame instructions, historically have used the form prefix_vendor_id_name, where vendor_id is some identifying character sequence chosen so as to avoid conflicts with other vendors. This established convention can continue in the cases where there is historical precedent or where there is a vendor but it can also be the name of the producer's project when there is no specific vendor.
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:
Section 7.32 Type Signature Computation
In the 3rd paragraph of point 4 replace “vendor-specific attributes” with “producer-specific attributes”.
Appendix A
In the first paragraph, replace “and new, vendor-defined ones” with “and producer defined ones”
Appendix D.7.3
In the text between the examples replace “vendor-specific” with “producer-specific” in both cases.
2024-03-25: Split from 231110.1.
