[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