BasicCABI.md: mention how function pointers look like #200
Conversation
BasicCABI.md
Outdated
| @@ -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 the table 0 of the module. | |||
There was a problem hiding this comment.
| A pointer to a function is an index into the table 0 of the module. | |
| A pointer to a function is an index into table 0 of the module. |
There was a problem hiding this comment.
I think __indirect_function_table might not be table 0. For example, if the module happens to import a table, since import always come first in the index space there is no way for the linker to arrange for __indirect_function_table to be at index 0.
In other words, any documentation like this should probably refer to the table by name on only.
There was a problem hiding this comment.
on runtime (eg. when calling a host function which takes a function pointer), the name is not available, is it?
There was a problem hiding this comment.
i was confused with linker symbol and export name.
i dropped table 0 assumption.
|
|
||
| A pointer to a function is an index into the table 0 of the module. | ||
| The type of the table is funcref. | ||
| The table needs to be exported with the name `__indirect_function_table` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
No description provided.