[PATCH] D40724: Wasm entrypoint changes #1 (add --undefined argument to LLD) APPLY AFTER D40690

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 1 11:18:10 PST 2017


sbc100 added inline comments.


================
Comment at: test/wasm/load-undefined.ll:10
+; RUN: obj2yaml %t.wasm | FileCheck %s
+
+
----------------
Could you add test for when the undefined symbol is not found?   i.e. -u foo should cause a certain linker error?  (unless we decide it doesn't, see below.)

(You can just add that case to within this file I think).


================
Comment at: wasm/Driver.cpp:292
+    for (StringRef S : Undefined)
+      addSyntheticUndefinedFunction(S, nullptr);
+
----------------
Hmm.. if we allow function symbols to have a null type I'm afraid we won't be able to represent them in the output object (since we can have an import or and export without a function type.  Perhaps this is OK if we know these symbols will never appear in the output, but I'm worried that --allow-undefined will allow them to appear.

Also, I was experimenting with --undefined with GNU ld.  The behaviour seems to be that if the symbol can't be found it simply results in an undefined symbol in the final output, not a link error.  Which I find strange, but maybe we can to mimik that?


================
Comment at: wasm/Symbols.h:72
 
+  bool hasFunctionType() const { return FunctionType; }
   const WasmSignature &getFunctionType() const;
----------------
I think its more clear if you explicitly compare with nullptr here.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D40724





More information about the llvm-commits mailing list