[PATCH] lld] handle the case of errors from createLinkerInput

[Shankar Kalpathi Easwaran]

================
Comment at: include/lld/Driver/CoreInputGraph.h:49
@@ +48,3 @@
+    llvm_unreachable("not handling errors");
+  }
+
----------------
Rui Ueyama wrote:
> I'd move this method to FileNode and remove duplciate member functions calling llvm_unreachable() from the subclasses.
Yes, makes sense.

================
Comment at: include/lld/Driver/GnuLDInputGraph.h:77
@@ -72,2 +76,3 @@
   bool _asNeeded : 1;
+  bool _isDashlPrefix : 1;
   std::vector<StringRef> _libraryPaths;
----------------
Rui Ueyama wrote:
> Why did you make them bitfields? I think we don't usually make boolean fields bitfields only because they need only 1 bit.
bool is an alias for a char, which takes a byte instead of a bit.

Below is an example :-

#include <stdio.h>

struct x {
bool a:1;
bool b:1;
bool c:1;
};

struct y {
  bool a;
  bool b;
  bool c;
};

int main() {
  printf("%ld\n",sizeof(struct x));
  printf("%ld\n",sizeof(struct y));
}

Prints :
1
3


================
Comment at: lib/Driver/GnuLdDriver.cpp:99
@@ +98,3 @@
+  return "Unknown Error";
+}
+
----------------
Rui Ueyama wrote:
> Looks like this is the only method that really implements errStr(). Do you think we can use one function to stringize error code, instead of defining member functions for each FileNode? Looks like we can just remove "-l"from message (make it "Unable to find library" + path) to make it sense in all platforms.
I want to make this part of the filenode, each FileNode can construct the error message in whichever way it wants. On ELF I want to distinguish between an actual library thats tried to be looked up using -l and an actual library specified in the link line.

================
Comment at: lib/Driver/GnuLdDriver.cpp:96
@@ +95,3 @@
+      return (Twine("Unable to find library -l") + _path).str();
+    return (Twine("Unable to find file ") + _path).str();
+  }
----------------
Rui Ueyama wrote:
> Use-after-return?
I was avoiding calling the allocation routine here since the string is going to get immediately printed out, the string should still be available in the stack. It might be unsafe to make an assumption like that, will use allocateString


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