Modules¶

The binary encoding of modules is organized into sections. Most sections correspond to one component of a module record, except that function definitions are split into two sections, separating their type declarations in the function section from their bodies in the code section.

Note

This separation enables parallel and streaming compilation of the functions in a module.

Indices¶

All indices are encoded with their respective value.

\begin{array}{r} \begin{array}{llclll} typeidx & ::= & x : u 32 & \Rightarrow & x \\ funcidx & ::= & x : u 32 & \Rightarrow & x \\ tableidx & ::= & x : u 32 & \Rightarrow & x \\ memidx & ::= & x : u 32 & \Rightarrow & x \\ globalidx & ::= & x : u 32 & \Rightarrow & x \\ elemidx & ::= & x : u 32 & \Rightarrow & x \\ dataidx & ::= & x : u 32 & \Rightarrow & x \\ localidx & ::= & x : u 32 & \Rightarrow & x \\ labelidx & ::= & l : u 32 & \Rightarrow & l \end{array} \end{array}

Sections¶

Each section consists of

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

Every section is optional; an omitted section is equivalent to the section being present with empty contents.

The following parameterized grammar rule defines the generic structure of a section with id $N$ and contents described by the grammar $B$ .

\begin{array}{r} \begin{array}{llcllll} {section}_{N} (B) & ::= & N : byte size : u 32 cont : B & \Rightarrow & cont & (if size = | | B | |) \\ | & ϵ & \Rightarrow & ϵ \end{array} \end{array}

For most sections, the contents $B$ encodes a vector. In these cases, the empty result $ϵ$ is interpreted as the empty vector.

Note

Other than for unknown custom sections, the $size$ is not required for decoding, but can be used to skip sections when navigating through a binary. The module is malformed if the size does not match the length of the binary contents $B$ .

The following section ids are used:

Id	Section
0	custom section
1	type section
2	import section
3	function section
4	table section
5	memory section
6	global section
7	export section
8	start section
9	element section
10	code section
11	data section
12	data count section

Custom Section¶

Custom sections have the id 0. They are intended to be used for debugging information or third-party extensions, and are ignored by the WebAssembly semantics. Their contents consist of a name further identifying the custom section, followed by an uninterpreted sequence of bytes for custom use.

\begin{array}{r} \begin{array}{llclll} customsec & ::= & {section}_{0} (custom) \\ custom & ::= & name {byte}^{*} \end{array} \end{array}

Note

If an implementation interprets the data of a custom section, then errors in that data, or the placement of the section, must not invalidate the module.

Type Section¶

The type section has the id 1. It decodes into a vector of function types that represent the $types$ component of a module.

\begin{array}{r} \begin{array}{llclll} typesec & ::= & {ft}^{*} : {section}_{1} (vec (functype)) & \Rightarrow & {ft}^{*} \end{array} \end{array}

Import Section¶

The import section has the id 2. It decodes into a vector of imports that represent the $imports$ component of a module.

\begin{array}{r} \begin{array}{llclll} importsec & ::= & {im}^{*} : {section}_{2} (vec (import)) & \Rightarrow & {im}^{*} \\ import & ::= & \mod : name nm : name d : importdesc & \Rightarrow & {module \mod, name nm, desc d} \\ importdesc & ::= & 0 x 00 x : typeidx & \Rightarrow & func x \\ | & 0 x 01 tt : tabletype & \Rightarrow & table tt \\ | & 0 x 02 mt : memtype & \Rightarrow & mem mt \\ | & 0 x 03 gt : globaltype & \Rightarrow & global gt \end{array} \end{array}

Function Section¶

The function section has the id 3. It decodes into a vector of type indices that represent the $type$ fields of the functions in the $funcs$ component of a module. The $locals$ and $body$ fields of the respective functions are encoded separately in the code section.

\begin{array}{r} \begin{array}{llclll} funcsec & ::= & x^{*} : {section}_{3} (vec (typeidx)) & \Rightarrow & x^{*} \end{array} \end{array}

Table Section¶

The table section has the id 4. It decodes into a vector of tables that represent the $tables$ component of a module.

\begin{array}{r} \begin{array}{llclll} tablesec & ::= & {tab}^{*} : {section}_{4} (vec (table)) & \Rightarrow & {tab}^{*} \\ table & ::= & tt : tabletype & \Rightarrow & {type tt} \end{array} \end{array}

Memory Section¶

The memory section has the id 5. It decodes into a vector of memories that represent the $mems$ component of a module.

\begin{array}{r} \begin{array}{llclll} memsec & ::= & {mem}^{*} : {section}_{5} (vec (mem)) & \Rightarrow & {mem}^{*} \\ mem & ::= & mt : memtype & \Rightarrow & {type mt} \end{array} \end{array}

Global Section¶

The global section has the id 6. It decodes into a vector of globals that represent the $globals$ component of a module.

\begin{array}{r} \begin{array}{llclll} globalsec & ::= & {glob}^{*} : {section}_{6} (vec (global)) & \Rightarrow & {glob}^{*} \\ global & ::= & gt : globaltype e : expr & \Rightarrow & {type gt, init e} \end{array} \end{array}

Export Section¶

The export section has the id 7. It decodes into a vector of exports that represent the $exports$ component of a module.

\begin{array}{r} \begin{array}{llclll} exportsec & ::= & {ex}^{*} : {section}_{7} (vec (export)) & \Rightarrow & {ex}^{*} \\ export & ::= & nm : name d : exportdesc & \Rightarrow & {name nm, desc d} \\ exportdesc & ::= & 0 x 00 x : funcidx & \Rightarrow & func x \\ | & 0 x 01 x : tableidx & \Rightarrow & table x \\ | & 0 x 02 x : memidx & \Rightarrow & mem x \\ | & 0 x 03 x : globalidx & \Rightarrow & global x \end{array} \end{array}

Start Section¶

The start section has the id 8. It decodes into an optional start function that represents the $start$ component of a module.

\begin{array}{r} \begin{array}{llclll} startsec & ::= & {st}^{?} : {section}_{8} (start) & \Rightarrow & {st}^{?} \\ start & ::= & x : funcidx & \Rightarrow & {func x} \end{array} \end{array}

Element Section¶

The element section has the id 9. It decodes into a vector of element segments that represent the $elems$ component of a module.

\begin{array}{r} \begin{array}{llclll} elemsec & ::= & {seg}^{*} : {section}_{9} (vec (elem)) & \Rightarrow & {seg}^{*} \\ elem & ::= & 0 : u 32 e : expr y^{*} : vec (funcidx) & \Rightarrow \\ {type funcref, init ((ref . func y) end)^{*}, mode active {table 0, offset e}} \\ | & 1 : u 32 et : elemkind y^{*} : vec (funcidx) & \Rightarrow \\ {type et, init ((ref . func y) end)^{*}, mode passive} \\ | & 2 : u 32 x : tableidx e : expr et : elemkind y^{*} : vec (funcidx) & \Rightarrow \\ {type et, init ((ref . func y) end)^{*}, mode active {table x, offset e}} \\ | & 3 : u 32 et : elemkind y^{*} : vec (funcidx) & \Rightarrow \\ {type et, init ((ref . func y) end)^{*}, mode declarative} \\ | & 4 : u 32 e : expr {el}^{*} : vec (expr) & \Rightarrow \\ {type funcref, init {el}^{*}, mode active {table 0, offset e}} \\ | & 5 : u 32 et : reftype {el}^{*} : vec (expr) & \Rightarrow \\ {type e t, init {el}^{*}, mode passive} \\ | & 6 : u 32 x : tableidx e : expr et : reftype {el}^{*} : vec (expr) & \Rightarrow \\ {type e t, init {el}^{*}, mode active {table x, offset e}} \\ | & 7 : u 32 et : reftype {el}^{*} : vec (expr) & \Rightarrow \\ {type e t, init {el}^{*}, mode declarative} \\ elemkind & ::= & 0 x 00 & \Rightarrow & funcref \end{array} \end{array}

Note

The initial integer can be interpreted as a bitfield. Bit 0 indicates a passive or declarative segment, bit 1 indicates the presence of an explicit table index for an active segment and otherwise distinguishes passive from declarative segments, bit 2 indicates the use of element type and element expressions instead of element kind and element indices.

Additional element kinds may be added in future versions of WebAssembly.

Code Section¶

The code section has the id 10. It decodes into a vector of code entries that are pairs of value type vectors and expressions. They represent the $locals$ and $body$ field of the functions in the $funcs$ component of a module. The $type$ fields of the respective functions are encoded separately in the function section.

The encoding of each code entry consists of

the $u 32$ size of the function code in bytes,
the actual function code, which in turn consists of
- the declaration of locals,
- the function body as an expression.

Local declarations are compressed into a vector whose entries consist of

a $u 32$ count,
a value type,

denoting count locals of the same value type.

\begin{array}{r} \begin{array}{llcllll} codesec & ::= & {code}^{*} : {section}_{10} (vec (code)) & \Rightarrow & {code}^{*} \\ code & ::= & size : u 32 code : func & \Rightarrow & code & (if size = | | func | |) \\ func & ::= & (t^{*})^{*} : vec (locals) e : expr & \Rightarrow & concat ((t^{*})^{*}), e & (if | concat ((t^{*})^{*}) | < 2^{32}) \\ locals & ::= & n : u 32 t : valtype & \Rightarrow & t^{n} \end{array} \end{array}

Here, $code$ ranges over pairs $({valtype}^{*}, expr)$ . The meta function $concat ((t^{*})^{*})$ concatenates all sequences $t_{i}^{*}$ in $(t^{*})^{*}$ . Any code for which the length of the resulting sequence is out of bounds of the maximum size of a vector is malformed.

Note

Like with sections, the code $size$ is not needed for decoding, but can be used to skip functions when navigating through a binary. The module is malformed if a size does not match the length of the respective function code.

Data Section¶

The data section has the id 11. It decodes into a vector of data segments that represent the $datas$ component of a module.

\begin{array}{r} \begin{array}{llclll} datasec & ::= & {seg}^{*} : {section}_{11} (vec (data)) & \Rightarrow & {seg}^{*} \\ data & ::= & 0 : u 32 e : expr b^{*} : vec (byte) & \Rightarrow & {init b^{*}, mode active {memory 0, offset e}} \\ | & 1 : u 32 b^{*} : vec (byte) & \Rightarrow & {init b^{*}, mode passive} \\ | & 2 : u 32 x : memidx e : expr b^{*} : vec (byte) & \Rightarrow & {init b^{*}, mode active {memory x, offset e}} \end{array} \end{array}

Note

The initial integer can be interpreted as a bitfield. Bit 0 indicates a passive segment, bit 1 indicates the presence of an explicit memory index for an active segment.

In the current version of WebAssembly, at most one memory may be defined or imported in a single module, so all valid active data segments have a $memory$ value of $0$ .

Data Count Section¶

The data count section has the id 12. It decodes into an optional u32 that represents the number of data segments in the data section. If this count does not match the length of the data segment vector, the module is malformed.

\begin{array}{r} \begin{array}{llclll} datacountsec & ::= & n^{?} : {section}_{12} (u 32) & \Rightarrow & n^{?} \end{array} \end{array}

Note

The data count section is used to simplify single-pass validation. Since the data section occurs after the code section, the $memory . init$ and $data . drop$ instructions would not be able to check whether the data segment index is valid until the data section is read. The data count section occurs before the code section, so a single-pass validator can use this count instead of deferring validation.

Modules¶

The encoding of a module starts with a preamble containing a 4-byte magic number (the string $‘ ∖ 0 asm ’$ ) and a version field. The current version of the WebAssembly binary format is 1.

The preamble is followed by a sequence of sections. Custom sections may be inserted at any place in this sequence, while other sections must occur at most once and in the prescribed order. All sections can be empty.

The lengths of vectors produced by the (possibly empty) function and code section must match up.

Similarly, the optional data count must match the length of the data segment vector. Furthermore, it must be present if any data index occurs in the code section.

\begin{array}{r} \begin{array}{llcllll} magic & ::= & 0 x 00 0 x 61 0 x 73 0 x 6 D \\ version & ::= & 0 x 01 0 x 00 0 x 00 0 x 00 \\ module & ::= & magic \\ version \\ {customsec}^{*} \\ {functype}^{*} : typesec \\ {customsec}^{*} \\ {import}^{*} : importsec \\ {customsec}^{*} \\ {typeidx}^{n} : funcsec \\ {customsec}^{*} \\ {table}^{*} : tablesec \\ {customsec}^{*} \\ {mem}^{*} : memsec \\ {customsec}^{*} \\ {global}^{*} : globalsec \\ {customsec}^{*} \\ {export}^{*} : exportsec \\ {customsec}^{*} \\ {start}^{?} : startsec \\ {customsec}^{*} \\ {elem}^{*} : elemsec \\ {customsec}^{*} \\ m^{?} : datacountsec \\ {customsec}^{*} \\ {code}^{n} : codesec \\ {customsec}^{*} \\ {data}^{m} : datasec \\ {customsec}^{*} \Rightarrow {\begin{matrix} types {functype}^{*}, \\ funcs {func}^{n}, \\ tables {table}^{*}, \\ mems {mem}^{*}, \\ globals {global}^{*}, \\ elems {elem}^{*}, \\ datas {data}^{m}, \\ start {start}^{?}, \\ imports {import}^{*}, \\ exports {export}^{*}} \end{matrix} \\ (if m^{?} \neq ϵ \lor dataidx ({code}^{n}) = \emptyset) \end{array} \end{array}

where for each $t_{i}^{*}, e_{i}$ in ${code}^{n}$ ,

\begin{array}{r} {func}^{n} [i] = {type {typeidx}^{n} [i], locals t_{i}^{*}, body e_{i}} \end{array}

Note

The version of the WebAssembly binary format may increase in the future if backward-incompatible changes have to be made to the format. However, such changes are expected to occur very infrequently, if ever. The binary format is intended to be forward-compatible, such that future extensions can be made without incrementing its version.