[PATCH] D145308: [lld][WebAssembly] Initial support for stub objects

[Sam Clegg via Phabricator via llvm-commits]

sbc100 added inline comments.


================
Comment at: lld/docs/WebAssembly.rst:78
 
+.. option:: --allow-undefined-file=<filename>
+
----------------
dschuff wrote:
> Can this be split out from the stub support? or is it tightly coupled somehow?
I just noticed it was missing from the docs.  Want me to split it out?  


================
Comment at: lld/docs/WebAssembly.rst:217
+Here we are saying that ``foo`` is allowed to be imported (undefined) but that
+if it is imported then the module must also export ``malloc`` and ``free``.  If
+``foo`` is undefined in the module, but the module does not define ``malloc``
----------------
dschuff wrote:
> Can you clarify this a little? which module must export malloc and free? The module that imports foo? Any module loaded before foo is loaded at runtime?
> 
> Why do we need to have this per-symbol dependence rather than just having a list of symbols that the dylib imports and exports? Is our linking model actually that granular at runtime?
Yes it needs to be on a per-symbol basis.   For example, imagine I just use one symbol from libemscripten.stub.so... and that symbol has no dependencies.  But there are 1000 other symbols in there with various dependencies, including malloc and free.

If we just did this on a per-shared-object bases any program that uses any symbol from libemscripten.stub.so would be forced to define and export the superset of all possible dependencies.   In that case of my tiny program I don't want to be forces to export anything, just to use emscripten_get_now, for example.


================
Comment at: lld/docs/WebAssembly.rst:217
+Here we are saying that ``foo`` is allowed to be imported (undefined) but that
+if it is imported then the module must also export ``malloc`` and ``free``.  If
+``foo`` is undefined in the module, but the module does not define ``malloc``
----------------
sbc100 wrote:
> dschuff wrote:
> > Can you clarify this a little? which module must export malloc and free? The module that imports foo? Any module loaded before foo is loaded at runtime?
> > 
> > Why do we need to have this per-symbol dependence rather than just having a list of symbols that the dylib imports and exports? Is our linking model actually that granular at runtime?
> Yes it needs to be on a per-symbol basis.   For example, imagine I just use one symbol from libemscripten.stub.so... and that symbol has no dependencies.  But there are 1000 other symbols in there with various dependencies, including malloc and free.
> 
> If we just did this on a per-shared-object bases any program that uses any symbol from libemscripten.stub.so would be forced to define and export the superset of all possible dependencies.   In that case of my tiny program I don't want to be forces to export anything, just to use emscripten_get_now, for example.
I tried to clarify a little.  I use the term "output module" to refer to the module being linked.  Perhaps you can think of a more clear way to express that?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145308/new/

https://reviews.llvm.org/D145308