From cad0ea9ed5f0ac1dda62abe2c66d0a38ff8c104d Mon Sep 17 00:00:00 2001 From: Seth Thompson Date: Wed, 26 Oct 2016 22:52:58 +0200 Subject: fix improperly spaced markdown blocks and typos (for formatting on website (#837) --- DynamicLinking.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'DynamicLinking.md') diff --git a/DynamicLinking.md b/DynamicLinking.md index c4329f8..52920c6 100644 --- a/DynamicLinking.md +++ b/DynamicLinking.md @@ -20,6 +20,7 @@ achieved by having module A export functions, tables and memories that are imported by B. A C++ toolchain can expose this functionality by using the same function attributes currently used to export/import symbols from native DSOs/DLLs: + ``` #ifdef _WIN32 # define EXPORT __declspec(dllexport) @@ -34,15 +35,19 @@ typedef void (**PF)(); IMPORT PF imp(); EXPORT void exp() { (*imp())(); } ``` + This code would, at a minimum, generate a WebAssembly module with imports for: + * the function `imp` * the heap used to perfom the load, when dereferencing the return value of `imp` * the table used to perform the pointer-to-function call and exports for: + * the function `exp` A more realistic module using libc would have more imports including: + * an immutable `i32` global import for the offset in linear memory to place global [data segments](Modules.md#data-section) and later use as a constant base address when loading and storing from globals @@ -57,6 +62,7 @@ toolchain to put implementation-internal names in a separate namespace, avoiding the need for `__`-prefix conventions). To implement run-time dynamic linking (e.g., `dlopen` and `dlsym`): + * `dlopen` would compile and instantiate a new module, storing the compiled instance in a host-environment table, returning the index to the caller. * `dlsym` would be given this index, pull the instance out of the table, -- cgit v1.2.3