Skip to content

Commit c0a7179

Browse files
authored
Merge pull request #65 from WebAssembly/add-producers-section
Add initial ProducersSection.md
2 parents 56376c8 + 22bec59 commit c0a7179

File tree

1 file changed

+109
-0
lines changed

1 file changed

+109
-0
lines changed

ProducersSection.md

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
# Producers Section
2+
3+
The purpose of the producers section is to provide an optional,
4+
highly-structured record of all the distinct tools that were used to produce
5+
a given WebAssembly module. A primary purpose of this record is to allow
6+
broad analysis of toolchain usage in the wild, which can help inform both wasm
7+
producers and consumers.
8+
9+
The producers section is a
10+
[custom section](https://webassembly.github.io/spec/core/binary/modules.html#custom-section)
11+
and thus has no semantic effects and can be stripped at any time.
12+
Since the producers section is relatively small, tools are encouraged to emit
13+
the section or include themselves in an existing section by default, keeping
14+
the producers section even in release builds.
15+
16+
WebAssembly consumers should avoid using the producers section to derive
17+
optimization hints. To ensure portable performance, hints should be
18+
standardized in a separate custom section, probably in the core spec's
19+
[Custom Sections appendix](https://webassembly.github.io/spec/core/appendix/custom.html).
20+
21+
An additional goal of the producers section is to provide a discrete, but
22+
easily-growable [list of known tools/languages](#known-list) for each
23+
record field. This avoids the skew that otherwise happens with unstructured
24+
strings. Unknown names do not invalidate an otherwise-valid producers section.
25+
However, wasm consumers may provide less accurate telemetry results for unknown
26+
names or even emit diagnostics encouraging the name to be put on the known list.
27+
28+
Since version information is useful, but highly-variable, each field value
29+
is accompanied with a version string so that the name can remain stable
30+
over time without requiring frequent updates to the known list.
31+
32+
## Custom Section
33+
34+
Custom section `name` field: `producers`
35+
36+
The producers section may appear only once, and only after the
37+
[Name section](https://webassembly.github.io/spec/core/appendix/custom.html#name-section).
38+
39+
The producers section contains a sequence of fields with unique names, where the
40+
end of the last field must coincide with the last byte of the producers section:
41+
42+
| Field | Type | Description |
43+
| ----------- | ----------- | ----------- |
44+
| field_count | `varuint32` | number of fields that follow |
45+
| fields | `field*` | sequence of field_count `field` records |
46+
47+
where a `field` is encoded as:
48+
49+
| Field | Type | Description |
50+
| ----------------- | ---- | ----------- |
51+
| field_name | [name][name-ref] | name of this field |
52+
| field_value_count | `varuint32` | number of value strings that follow |
53+
| field_values | `versioned-name*` | sequence of field_value_count name-value pairs |
54+
55+
where a `versioned-name` is encoded as:
56+
57+
| Field | Type | Description |
58+
| ------- | ---- | ----------- |
59+
| name | [name][name-ref] | name of the language/tool |
60+
| version | [name][name-ref] | version of the language/tool |
61+
62+
with the additional constraint that each field_name in the list must be unique
63+
and found in the first column of the following table, and each of a given field_name's
64+
field_values's name strings must be unique and found in the second column of
65+
the field_name's row.
66+
67+
| field_name | field_value name strings |
68+
| -------------- | -------------------- |
69+
| `language` | [source language list](#source-languages) |
70+
| `processed-by` | [individual tool list](#individual-tools) |
71+
| `sdk` | [SDK list](#sdks) |
72+
73+
[name-ref]: https://webassembly.github.io/spec/core/binary/values.html#names
74+
75+
## Known list
76+
77+
The following lists contain all the known names for the fields listed above.
78+
**If your tool is not on this list and you'd like it to be, please submit a PR.**
79+
80+
### Source Languages
81+
82+
It is possible for multiple source languages to be present in a single module
83+
when the output of multiple compiled languages are statically linked together.
84+
85+
* `wat`
86+
* `C`
87+
* `C++`
88+
89+
### Individual Tools
90+
91+
It is possible (and common) for multiple tools to be used in the overall
92+
pipeline that produces and optimizes a given wasm module.
93+
94+
* `wabt`
95+
* `LLVM`
96+
* `lld`
97+
* `Binaryen`
98+
99+
### SDKs
100+
101+
While an SDK is technically just another tool, the `sdk` field designates the
102+
top-level "thing" that the developer installs and interacts with directly to
103+
produce the wasm module.
104+
105+
* `Emscripten`
106+
107+
## Text format
108+
109+
TODO

0 commit comments

Comments
 (0)