[PATCH] [lld][ELF] Ability to resolve undefined symbols lazily

[Denis Protivensky]

Okay, since we drop this patch - I won't make any additional changes to it.


================
Comment at: include/lld/Core/Simple.h:105
@@ +104,3 @@
+
+  File *find(StringRef sym, bool dataSymbolOnly) override {
+    // For descendants:
----------------
ruiu wrote:
> I expect all subclasses need to implement this function, so it's better to not define this here, so that the compiler raises an error if definition is missing.
I deliberately added it while copying your implementation of virtual archive just because my understanding of Simple group of classes is that they are defaults that can be picked up and used as-is. In general, I agree that this method is excessive for the class. I'd rather say it shouldn't be in the Simple group, but I didn't find better place for it.

================
Comment at: lib/ReaderWriter/ELF/OutputELFWriter.h:70-78
@@ +69,11 @@
+
+    SymbolFile<ELFT> *file = _file.getValue();
+    assert (!file->hasAtoms() && "The file shouldn't have atoms yet");
+    _resolver(sym, file);
+    // If atoms were added - throw the file to the caller and prepare
+    // to create new one by resetting the holder.
+    if (file->hasAtoms()) {
+      _file.reset();
+      return file;
+    }
+    return nullptr;
----------------
shankarke wrote:
> Can you add a test where you have multiple absolute symbols being added, I dont see how this works. This is error prone and could we  create a new runtime file for every symbol, like a archive library.
As an alternative, think of such method prototype for derived classes:
`File* processUndefinedSymbol(StringRef symName);`

It forces the implementor to write spaghetti code that is more error prone than this (I thought about it during the implementation). I prefer to move the complexity to the base class and free the descendants from potential errors.

http://reviews.llvm.org/D8159

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/