Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify version and abi information in "linking" section header #56

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Specify version and abi information in "linking" section header #56

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 32 additions & 5 deletions Linking.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ section itself.
Relocation Sections
-------------------

A relocation section is a user-defined section with a name starting with
A relocation section is a custom section with a name starting with
"reloc." Relocation sections start with an identifier specifying which
section they apply to, and must be sequenced in the module after that
section.
Expand Down Expand Up @@ -104,11 +104,37 @@ body.
Linking Metadata Section
------------------------

A linking metadata section is a user-defined section with the name
"linking".
A linking metadata section is a custom section with the name "linking".

A linking metadata section contains a series of sub-sections layed
out in the same way as the ["names"][names_sec] section:
A linking metadata section begins with a header which is then followed by a
series of sub-sections laid out in the same way as the ["names"][names_sec]
section.

The header contains the following fields:

| Field | Type | Description |
| ----------- | ------------ | ---------------------------------- |
| version | `varuint32` | Metadata version number |
| abi | `varuint32` | ABI |
| abi_version | `varuint32` | ABI version number |
| abi_flags | `varuint32` | a bitfield of abi-specific flags |

The `version` field contains an integer version number which is updated each
time the linking metadata described in this documented is changed in an
incompatible way. Linkers and other tools can issue warnings or reject
incompatible inputs based on this version. The current metadata version is `1`
and the goal is to avoid updating this.

The `abi` specifies which ABI is used in by the code contained in the module.
Currently there is only one possible value for this field:

- `1 / WASM_ABI_CXX` - [WebAssembly C/C++ ABI][abi_cxx]

The `abi_version` field specifies the version of the ABI in use. This is used
to distinguish between incompatible versions of the same ABI. The current
version of `WASM_ABI_CXX` is `1`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned about mixing C++ in with C here. The C++ ABI is likely to evolve on its own schedule, with things like using wasm tables to implement vtables, wasm exception handling, coroutines, and it would be unfortunate to impose ABI version bumps on people using the C ABI when these things happen. So at the very least, my suggestion is to at least have a field for just the C ABI.

But also, looking ahead to exception handling -- it would be nice if C++ users that aren't using exceptions at all don't have to worry about incompatibilities when EH happens. Their code should be compatible with both setjump-longjmp EH code and wasm-EH code. And other C++ features may end up in similar predicaments. So brainstorming, what if we made the ABI field be an array of key-value pairs? The keys could be named integers (WASM_ABI_*), and the values could be whatever makes sense for a given key. A binary could declare something like WASM_ABI_LINKING=1, WASM_ABI_C=1, WASM_ABI_C++ABI=ITANIUM, WASM_ABI_C++ABI_VERSION=1, WASM_ABI_EH=false or something. Thoughts?


Each subsection contains the following fields:

| Field | Type | Description |
| ------------ | ----------- | ------------------------------------ |
Expand Down Expand Up @@ -349,3 +375,4 @@ the value of the relocation shall be `0`.


[names_sec]: https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#name-section
[abi_cxx]: https://github.com/WebAssembly/tool-conventions/blob/master/BasicCABI.md