[PATCH] [lld][ELF] Add undefined symbol option to lld

[Shankar Kalpathi Easwaran]

================
Comment at: test/elf/X86_64/undef.test:4
@@ +3,3 @@
+# which is usually the usecase for it
+RUN: lld -flavor gnu -target x86_64 -u fn %p/Inputs/libfn.a -o %t --noinhibit-exec
+RUN: llvm-readobj -symbols %t | FileCheck -check-prefix=SYMFROMARCHIVE %s
----------------
Rui Ueyama wrote:
> Could you write a test using the same command line options except "-u fn", to verify that "fn" will not be emit in that case?
Ok.

================
Comment at: lib/ReaderWriter/ELF/OutputELFWriter.h:237
@@ -225,3 +236,3 @@
 
-template<class ELFT>
-void OutputELFWriter<ELFT>::createDefaultSections() {
+template <class ELFT>
+void OutputELFWriter<ELFT>::addFiles(InputFiles &inputFiles) {
----------------
Rui Ueyama wrote:
> virtual?
Already virtual, see the class declaration.

================
Comment at: lib/ReaderWriter/ELF/ExecutableWriter.h:66
@@ -65,2 +65,3 @@
 template <class ELFT>
 void ExecutableWriter<ELFT>::addFiles(InputFiles &inputFiles) {
+  // Add the default atoms as defined by executables
----------------
Rui Ueyama wrote:
> Make this a virtual method?
already virtual, see the class declaration.

================
Comment at: lib/Driver/LDOptions.td:77
@@ +76,3 @@
+    HelpText<"Force symbol to be entered in the output file as an undefined symbol">;
+def u_alias : Joined<["--"], "undefined=">, Alias<u>;
+
----------------
Rui Ueyama wrote:
> Looks like GNU accepts all the following flags:
> 
>  1. -u foo
>  2. -u=foo
>  3. --undefined foo
>  4. --undefined=foo
> 
> I think with this patch lld will accept only case 1 and 4. Does the LLVM command option handler the capability to handle all these cases?
The option handler supports all combinations, will add them.

================
Comment at: include/lld/ReaderWriter/ELFTargetInfo.h:200
@@ -182,2 +199,3 @@
   StringRef                          _dynamicLinkerPath;
+  StringRefVector _undefinedSymbols;
 };
----------------
Rui Ueyama wrote:
> Align horizontally. That's probably not LLVM coding style but local consistency is more important than that, I think (unless we fix all the above style).
Ok.


http://llvm-reviews.chandlerc.com/D997