Custom Sections and Annotations¶

This appendix defines dedicated custom sections for WebAssembly’s binary format and annotations for the text format. Such sections or annotations do not contribute to, or otherwise affect, the WebAssembly semantics, and may be ignored by an implementation. However, they provide useful meta data that implementations can make use of to improve user experience or take compilation hints.

Name Section¶

The name section is a custom section whose name string is itself $‘ name ’$ . The name section should appear only once in a module, and only after the data section.

The purpose of this section is to attach printable names to definitions in a module, which e.g. can be used by a debugger or when parts of the module are to be rendered in text form.

Note

All names are represented in Unicode encoded in UTF-8. Names need not be unique.

Subsections¶

The data of a name section consists of a sequence of subsections. Each subsection consists of a

a one-byte subsection id,
the $u 32$ size of the contents, in bytes,
the actual contents, whose structure is dependent on the subsection id.

\begin{array}{r} \begin{array}{llcll} namesec & ::= & {section}_{0} (namedata) \\ namedata & ::= & n : name & (if n = ‘ name ’) \\ {modulenamesubsec}^{?} \\ {funcnamesubsec}^{?} \\ {localnamesubsec}^{?} \\ {typenamesubsec}^{?} \\ {fieldnamesubsec}^{?} \\ {tagnamesubsec}^{?} \\ {namesubsection}_{N} (B) & ::= & N : byte size : u 32 B & (if size = | | B | |) \end{array} \end{array}

The following subsection ids are used:

Id	Subsection
0	module name
1	function names
2	local names
4	type names
10	field names
11	tag names

Each subsection may occur at most once, and in order of increasing id.

Name Maps¶

A name map assigns names to indices in a given index space. It consists of a vector of index/name pairs in order of increasing index value. Each index must be unique, but the assigned names need not be.

\begin{array}{r} \begin{array}{llclll} namemap & ::= & vec (nameassoc) \\ nameassoc & ::= & idx name \end{array} \end{array}

An indirect name map assigns names to a two-dimensional index space, where secondary indices are grouped by primary indices. It consists of a vector of primary index/name map pairs in order of increasing index value, where each name map in turn maps secondary indices to names. Each primary index must be unique, and likewise each secondary index per individual name map.

\begin{array}{r} \begin{array}{llclll} indirectnamemap & ::= & vec (indirectnameassoc) \\ indirectnameassoc & ::= & idx namemap \end{array} \end{array}

Module Names¶

The module name subsection has the id 0. It simply consists of a single name that is assigned to the module itself.

\begin{array}{r} \begin{array}{llclll} modulenamesubsec & ::= & {namesubsection}_{0} (name) \end{array} \end{array}

Function Names¶

The function name subsection has the id 1. It consists of a name map assigning function names to function indices.

\begin{array}{r} \begin{array}{llclll} funcnamesubsec & ::= & {namesubsection}_{1} (namemap) \end{array} \end{array}

Local Names¶

The local name subsection has the id 2. It consists of an indirect name map assigning local names to local indices grouped by function indices.

\begin{array}{r} \begin{array}{llclll} localnamesubsec & ::= & {namesubsection}_{2} (indirectnamemap) \end{array} \end{array}

Type Names¶

The type name subsection has the id 4. It consists of a name map assigning type names to type indices.

\begin{array}{r} \begin{array}{llclll} typenamesubsec & ::= & {namesubsection}_{4} (namemap) \end{array} \end{array}

Field Names¶

The field name subsection has the id 10. It consists of an indirect name map assigning field names to field indices grouped by the type indices of their respective structure types.

\begin{array}{r} \begin{array}{llclll} fieldnamesubsec & ::= & {namesubsection}_{1} 0 (indirectnamemap) \end{array} \end{array}

Tag Names¶

The tag name subsection has the id 11. It consists of a name map assigning tag names to tag indices.

\begin{array}{r} \begin{array}{llclll} tagnamesubsec & ::= & {namesubsection}_{1} (namemap) \end{array} \end{array}

Name Annotations¶

Name annotations are the textual analogue to the name section and provide a textual representation for it. Consequently, their id is $@ name$ .

Analogous to the name section, name annotations are allowed on modules, functions, and locals (including parameters). They can be placed where the text format allows binding occurrences of respective identifiers. If both an identifier and a name annotation are given, the annotation is expected after the identifier. In that case, the annotation takes precedence over the identifier as a textual representation of the binding’s name. At most one name annotation may be given per binding.

All name annotations have the following format:

\begin{array}{r} \begin{array}{llclll} nameannot & ::= & ‘ (@ name ’ string ‘) ’ \end{array} \end{array}

Note

All name annotations can be arbitrary UTF-8 strings. Names need not be unique.

Module Names¶

A module name annotation must be placed on a module definition, directly after the $‘ module ’$ keyword, or if present, after the following module identifier.

\begin{array}{r} \begin{array}{llclll} modulenameannot & ::= & nameannot \end{array} \end{array}

Function Names¶

A function name annotation must be placed on a function definition or function import, directly after the $‘ func ’$ keyword, or if present, after the following function identifier or.

\begin{array}{r} \begin{array}{llclll} funcnameannot & ::= & nameannot \end{array} \end{array}

Parameter Names¶

A parameter name annotation must be placed on a parameter declaration, directly after the $‘ param ’$ keyword, or if present, after the following parameter identifier. It may only be placed on a declaration that declares exactly one parameter.

\begin{array}{r} \begin{array}{llclll} paramnameannot & ::= & nameannot \end{array} \end{array}

Local Names¶

A local name annotation must be placed on a local declaration, directly after the $‘ local ’$ keyword, or if present, after the following local identifier. It may only be placed on a declaration that declares exactly one local.

\begin{array}{r} \begin{array}{llclll} localnameannot & ::= & nameannot \end{array} \end{array}

Type Names¶

A type name annotation must be placed on a type declaration, directly after the $‘ type ’$ keyword, or if present, after the following type identifier.

\begin{array}{r} \begin{array}{llclll} typenameannot & ::= & nameannot \end{array} \end{array}

Field Names¶

A field name annotation must be placed on the field of a structure type, directly after the $‘ field ’$ keyword, or if present, after the following field identifier. It may only be placed on a declaration that declares exactly one field.

\begin{array}{r} \begin{array}{llclll} fieldnameannot & ::= & nameannot \end{array} \end{array}

Tag Names¶

A tag name annotation must be placed on a tag declaration or tag import, directly after the $‘ tag ’$ keyword, or if present, after the following tag identifier.

\begin{array}{r} \begin{array}{llclll} tagnameannot & ::= & nameannot \end{array} \end{array}

Custom Annotations¶

Custom annotations are a generic textual representation for any custom section. Their id is $@ custom$ . By generating custom annotations, tools converting between binary format and text format can maintain and round-trip the content of custom sections even when they do not recognize them.

Custom annotations must be placed inside a module definition. They must occur anywhere after the $‘ module ’$ keyword, or if present, after the following module identifier. They must not be nested into other constructs.

\begin{array}{r} \begin{array}{llclll} customannot & ::= & ‘ (@ custom ’ string {customplace}^{?} datastring ‘) ’ \\ customplace & ::= & ‘ (’ ‘ before ’ ‘ first ’ ‘) ’ \\ | & ‘ (’ ‘ before ’ \sec ‘) ’ \\ | & ‘ (’ ‘ after ’ \sec ‘) ’ \\ | & ‘ (’ ‘ after ’ ‘ last ’ ‘) ’ \\ \sec & ::= & ‘ type ’ \\ | & ‘ import ’ \\ | & ‘ func ’ \\ | & ‘ table ’ \\ | & ‘ memory ’ \\ | & ‘ global ’ \\ | & ‘ export ’ \\ | & ‘ start ’ \\ | & ‘ elem ’ \\ | & ‘ code ’ \\ | & ‘ data ’ \\ | & ‘ datacount ’ \end{array} \end{array}

The first string in a custom annotation denotes the name of the custom section it represents. The remaining strings collectively represent the section’s payload data, written as a data string, which can be split up into a possibly empty sequence of individual string literals (similar to data segments).

An arbitrary number of custom annotations (even of the same name) may occur in a module, each defining a separate custom section when converting to binary format. Placement of the sections in the binary can be customized via explicit placement directives, that position them either directly before or directly after a known section. That section must exist and be non-empty in the binary encoding of the annotated module. The placements $(before first)$ and $(after last)$ denote virtual sections before the first and after the last known section, respectively. When the placement directive is omitted, it defaults to $(after last)$ .

If multiple placement directives appear for the same position, then the sections are all placed there, in order of their appearance in the text. For this purpose, the position $after$ a section is considered different from the position $before$ the consecutive section, and the former occurs before the latter.

Note

Future versions of WebAssembly may introduce additional sections between others or at the beginning or end of a module. Using $first$ and $last$ guarantees that placement will still go before or after any future section, respectively.

If a custom section with a specific section id is given as well as annotations representing the same custom section (e.g., $@ name$ annotations as well as a $@ custom$ annotation for a $name$ section), then two sections are assumed to be created. Their relative placement will depend on the placement directive given for the $@ custom$ annotation as well as the implicit placement requirements of the custom section, which are applied to the other annotation.

Note

For example, the following module,

(module
  (@custom "A" "aaa")
  (type $t (func))
  (@custom "B" (after func) "bbb")
  (@custom "C" (before func) "ccc")
  (@custom "D" (after last) "ddd")
  (table 10 funcref)
  (func (type $t))
  (@custom "E" (after import) "eee")
  (@custom "F" (before type) "fff")
  (@custom "G" (after data) "ggg")
  (@custom "H" (after code) "hhh")
  (@custom "I" (after func) "iii")
  (@custom "J" (before func) "jjj")
  (@custom "K" (before first) "kkk")
)

will result in the following section ordering:

custom section "K"
custom section "F"
type section
custom section "E"
custom section "C"
custom section "J"
function section
custom section "B"
custom section "I"
table section
code section
custom section "H"
custom section "G"
custom section "A"
custom section "D"