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

[Derek Schuff via Phabricator via llvm-commits]

dschuff added inline comments.


================
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:
> 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?
But isn't it the case that a stub library represents a real DSO that will be loaded at runtime? (I think that's the case with ELF stubs). In which case the real DSO has whatever symbols and dependencies it has.

I guess the answer is actually "no", we are depending on the behavior that libemscripten isn't really a DSO, but it acts more like an archive with one function per member, i.e. each function will only be linked if it is needed.

I think in that sense, this isn't really a "stub object" at all, and has kind of weird linking behavior. 

Is there any way we can improve this, to make stub objects behave more like regular objects or DSOs? I don't think we want to create a stub object for every JS function, that would get unwieldy very fast. Maybe a "stub archive" that can define multiple objects (and we'd just have one such object for every JS function).
Am I making sense here? I would be happier if this functionality were of more general use that only emscripten's JS use case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145308