[PATCH] D41922: [WebAssembly] When loading libraries look for companion `.imports` file

[Sam Clegg via Phabricator via llvm-commits]

sbc100 added a comment.

In https://reviews.llvm.org/D41922#990507, @ncw wrote:

> I've been having further thoughts about this `libc.imports` business.
>
> What I'm doing in my "minscripten" minimal Wasm toolchain turns the problem the other way up: it's //not// the business of a library file like `libc.a` to declare what symbols it "imports". Instead, at the point when you link, the linker should have all the JavaScript files and so on all available - so as a pre-link step, Emscripten should be //generating// the `--allow-undefined-symbols` file based on the JavaScript symbols. Emscripten definitely knows what JS symbols are available at the point when it invokes LLD via Clang, so it should be telling LLD which symbols are allowed to be imported.


I'm not sure about that.  Isn't it libc that knows exactly what symbols it expects to come from the embeder?  Sure with emscripten we could imagine a complex compiler driver that is aware of all the JS functions and construct a long list of possible imports to be passed to linker, but I don't think that a very nice approach and requires complexity in the driver that it would nice to avoid.   I like Dan's approach to being able to mark such function in the source language: https://reviews.llvm.org/D42520.

In any case it seems like we can support both methods: import defined by the libraries you link as well as explicitly allowed imports via the linker command line.

On this topic I was considering removing --allow-undefined-file since we are no longer using it.. and perhaps renaming --allow-undefined to --import (to match the existing --export).  Are you using these flags currently in your toolchain?


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D41922