search

WebAssembly / tool-conventions

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

Symbol metadata for dynamic linking #154

Open sbc100 opened 3 years ago

sbc100 commented 3 years ago

The current (experimental) dynamic linking ABI doesn't support any kind of symbol information other than the imports and exports of a module. It does use a small custom "dylink" section but currently has no per-symbol information.

In order to support dynamic linking along + threading (https://github.com/emscripten-core/emscripten/issues/3494) and in order to support weak symbol references (https://github.com/emscripten-core/emscripten/issues/12826) emscripten needs some way to add flags to symbols. Specifically for dynamic linking we need way to mark a given export is TLS and for weak externals we need to way to mark a given import as WEAK.

I think we have 2 options:

  1. Add thing information into the import or export name itself
  2. Use a custom section.

(1) sounds unattractive since it involved name mangling. However the number of flags we need to is unlikely to grow much (if at all). We could allow for example the @tls suffix on exports and the @weak suffix on imports.

For (2) we would presumably add to the existing dylink section. However we don't currently part the dylink section of the main executable at runtime so that would be something we would have to start doing. If we go with (2) we would need to invent some kind of dynamic symbol table.

Of course in the long term we want to use module linking, but I don't think there is any support for either TLS or weak symbols in the current or planed module linking proposal.

sbc100 commented 3 years ago

@dschuff

dschuff commented 3 years ago

So for mangling, we currently have @PLT and we might add @tls and @weak? Do we think we'd ever have something like ELF-style symbol versioning? I guess ELF has both mangling and a separate symbol table, right? I wonder why that is...

sbc100 commented 3 years ago

The current scheme is that we import from the GOT.mem and GOT.func modules for data and function address. e.g. and import of foo from GOT.func is the address of function foo in the wasm table of bar from GOT.mem is the absolute address of bar in memory.

This only apply to imports so we have second level of namespace. For exports we have not namespace. We export data address as wasm globals and we never export function addresses, only first-class functions. All data address exports are currently assumed to be __memory_base relative.