search

WebAssembly / tool-conventions

Conventions supporting interoperatibility between tools working with WebAssembly.
Artistic License 2.0
298 stars 65 forks source link

Dynamic Linking: imports module name #135

Open Geertiebear opened 4 years ago

Geertiebear commented 4 years ago

Hello,

I have been experimenting with wasm dynamic linking, and have a question. If I define a module foo which depends on the function f in module bar, using the --shared linker flag bar gets put into the dylink section of foo. The function f gets put in the import section along with the other needed globals and memories etc. However, the module name argument of the import of f is env, and not bar. So the import becomes env.f and not bar.f.

Is this intended behaviour? And if so, why? I would expect the module name for the import to be the actual name of the module the import originates from. It also seems logical to have the module name env reserved for imports that the interpreter provides, such as functions to interact with the interpreter.

Geertiebear commented 4 years ago

bump

sbc100 commented 4 years ago

The current DLL linking that exists in emscripten (and in draft form here) does not use a two level namespace.

All symbols that take part in the DLL linkable will appear under "env". This is mostly for historical reasons and the plan is to move away from that.

How are you declaring the name of the module you want f to come from? I imagine that the final proposal we land on will not allow you to control DLL linkage symbols using the import_name and import_module attributes. The module name will most likely match the name (SO_NAME) of the DLL the that the static linker sees the symbols coming from. E.g. "lib.so" . "printf". Do you see any reason not to just go with the SO_NAME as the module name ?

Geertiebear commented 4 years ago

This is mostly for historical reasons and the plan is to move away from that.

That's nice. I was wondering if this was intended/planned behavior, so if it's just for historical reasons that is a good answer to my question.

How are you declaring the name of the module you want f to come from? Do you see any reason not to just go with the SO_NAME as the module name ?

I'm not declaring the import name of f and when I first experimented with this I expected f to be the same as SO_NAME. So no I don't see any reason not to just go with SO_NAME as the module name.

I guess it is not a pressing problem, but my first instinct was to have separate maps for host functions and module functions, so it's easy to differentiate between them. But tagged unions work just fine in that case as well so it's probably not such a big deal. Regardless, thank you for your answer.

dschuff commented 2 years ago

Now is probably a good time to revisit this, as we are developing the next generation of dynamic linking.