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

Shankar Kalpathi Easwaran shankarke at gmail.com
Mon Mar 9 07:44:11 PDT 2015


================
Comment at: include/lld/Core/LinkingContext.h:310
@@ -309,2 +309,3 @@
   // This function is called just before the Resolver kicks in.
   // Derived classes may use that chance to rearrange the input files.
+  virtual void finalizeInputFiles() {}
----------------
Can you change the comment to specify the new functionality ?

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMExecutableWriter.h:45
@@ -45,1 +44,3 @@
+
+  static const StringRef gotSymbol;
 };
----------------
why static const ? StringRef is already a const. Strange way of initializing.

================
Comment at: lib/ReaderWriter/ELF/ARM/ARMExecutableWriter.h:49
@@ -47,1 +48,3 @@
 template <class ELFT>
+const StringRef ARMExecutableWriter<ELFT>::gotSymbol = "_GLOBAL_OFFSET_TABLE_";
+
----------------
remove const from StringRef.

================
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;
----------------
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.

http://reviews.llvm.org/D8159

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






More information about the llvm-commits mailing list