Skip to content

BasicCABI.md: mention how function pointers look like #200

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

BasicCABI.md: mention how function pointers look like #200

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ae83408
BasicCABI.md: mention how function pointers look like
yamt Feb 20, 2023
daf2f35
drop a table 0 assumption
yamt Apr 14, 2023
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
9 changes: 9 additions & 0 deletions BasicCABI.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,15 @@ Bitfield type | Witdh *w* | Range
`signed long long` | 1 to 64 | -2<sup>(w-1)</sup> to 2<sup>(w-1)</sup>-1
`long long`, `unsigned long long` | 1 to 64 | 0 to 2<sup>w</sup>-1

**Function pointers**

A pointer to a function is an index into a table of the module.
The type of the table is funcref.
The table needs to be exported with the name `__indirect_function_table`
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 not sure if this should be a requirement of the base C ABI. IIRC it is what emscripten does, but emscripten is also focused on the JS embedding (and has other conventions such as other exports that are also beyond the scope of this doc). There are also other ways to accomplish the same objective (for example, a module could export a function that takes the function pointer as an argument, and then calls it itself).
Probably it makes sense for conventions used by particular embeddings or particular SDKs/runtimes to be either left out of this doc or put in a separate section. Is this requirement particularly important to the environment that you are using?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are also other ways to accomplish the same objective (for example, a module could export a function that takes the function pointer as an argument, and then calls it itself).

yes. but sometimes it isn't desirable to tweak the api that way. eg. when it's from a standard. or when it's a port from non-wasm platform.

Probably it makes sense for conventions used by particular embeddings or particular SDKs/runtimes to be either left out of this doc or put in a separate section. Is this requirement particularly important to the environment that you are using?

i'm not familiar with emscripten.

my concern is more about wasi: https://github.com/WebAssembly/WASI/blob/main/legacy/application-abi.md#current-unstable-abi

if the function pointer is possibly used from the outside of the module.
Eg. If the module passes a function pointer to a host function as
a callback.

**SIMD Vector types**

The ABI for vector types is not stable and may change as new optimization opportunities are
Expand Down