ELF: Define another entry point.

[ruiu]

Summary

This is a drop-in replacement for the old ELF's lld::elf::link.
It takes the same parameters and does the same thing (link object files.)

Unlike elf2::link, elf2::main is guaranteed to return. Internally,
it uses fork (on Unix) or CreateProcess (on Windows), but that should
be considered as an internal detail in most cases. We may change the
implementation in future.

[ruiu]

Fixed a bug in the Windows version.

[ruiu]

Made the Windows version slightly better.

[• rafael]

Would it be too bad to use the windows version for unix too for now to avoid the #ifdef?

This is fine from the perspective of providing a safe api with a really small code cost on our side. Please get a LGTM too from an intended user.

Thanks a lot for doing this.

ELF/Driver.h

31

Maybe call this one link and the old link becomes linkOrFali?

ELF/DriverUtils.cpp

139

both close and dup can fail, not sure if you care in here.

[ruiu]

It is better to keep Unix version being separated from Windows, because on Unix, there is no reliable way to find the executable on the filesystem. On Linux, you can always use /proc/self/exe, but that's highly platform-dependent. So the most reliable way is to not exec anything.

ELF/Driver.h

31

Done.

ELF/DriverUtils.cpp

139

We should be able to ignore errors safely here. I close stdin here just to make the child process behave nicely if it ever tries to read input from stdin (that should never succeed). This is just a safety measure.

[ruiu]

• Updated as per Rafael's comments.

[silvas]

ELF/DriverUtils.cpp

143

It is not safe to call link after a fork, since e.g. the malloc lock can be held after forking in a multi-threaded situation.

http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html

A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. ***Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.*** [THR] [Option Start]  Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls.

You can find a list of async-signal safe functions here: http://man7.org/linux/man-pages/man7/signal.7.html

In other words, you pretty much have to exec in order to be robust when used from a multi-threaded program (and sometimes there are threads internal to the runtime library so any program can be multi-threaded). Your LLVM_ON_UNIX==false seems portable so I think you can just delete the LLVM_ON_UNIX==true version.

194

The documentation states that this function is guaranteed to return. So it can't call error.

[ruiu]

• Use MemoryBuffer to read from an FD instead of read(2).

[ruiu]

• Update as per Sean's comments.

[ruiu]

ELF/DriverUtils.cpp

143

That is very true. I thought that I knew the risk of not calling exec right after fork, but there were more than I expected. I removed the code for Unix and merged that with Windows code.

167

Fixed.

[davide]

I like it.

ELF/DriverUtils.cpp

128

The double cast is not exactly pretty, but I'm not exactly sure there's a way to avoid it.

[ruiu]

ELF/DriverUtils.cpp

128

I took this line from Clang. We may be able to remove (intptr_t), and just do (void *).

[davide]

ELF/DriverUtils.cpp

128

Fair enough, assuming GCC or clang don't complain

[arseny.kapoulkine]

I *believe* (although I have not tested this) that the original version of this patch with fork() will work for me as is.

The existing version assumes that the executable-to-call is lld which is not installed on my system. Since the use case for lld-as-a-library involves linking lld into the calling process this probably makes sense.

I tried replacing getLldExecutable() body with "return std::string(Arg0)" as a hack; passing argv[0] from my compiler driver into elf2::link and handling -flavor gnu -lld-no-exec prefix as a signal to call linkOrFail works fine. Of course this requires parent process to actively participate in this form of dispatch :( I was originally assuming that we'd be able to fork() and then everything will just work without extra setup.

[ruiu]

Ah, right, if you link lld with your program, lld may not exist as an independent command file on your system. You may be able to install lld along with your command, but the whole point of this patch is to provide an easy migration path for existing users, so it wouldn't make much sense, I guess.

Maybe I should switch back to use fork on Unix, with a notice saying that you shouldn't use in a multi-threaded program. Or, if wouldn't work, we can just throw this patch out and wait until we do real stuff. I want to try a few ideas to handle errors in a better way that would probably make link() always return, so maybe we can live without this.

[• rafael]

I just reread the related threads, let me try to summarize:

• Some user caused errors (duplicated symbols for example) are better

handled with non-fatal handling. Since that doesn't impact libraries
and we want it anyway, lets just ignore those in here (i.e.:, use this
to look at the hard issues).

• I would really not want us to be in a situation where we have bugs

but they are not fixed. If not failing gracefully given broken files
is to be considered a bug, we *have* to fuzz the linker and fix them.
A particularly nasty case is relocations being used in ABI invalid
cases. For example, if a R_X86_64_REX_GOTPCRELX is used in a position
that doesn't follow a REX prefix, do we have to report the error or
can we produce garbage when given garbage? Note that checking means
disassembling the entire section to see if a given byte is a rex
prefix for a instruction or just a byte of the previous instruction.

The options I see then are:

A) Fuzz the linker, make sure it can handle every combination of
broken file we can throw at it. This is a lot of work and not
something I will sign up for. I can help review and benchmark, but I
would also ask that this be delayed. We are still refactoring the
linker as features are added and I losing the simplicity we have now
would be really bad for design work.

B) Provide a way of isolating the liking "task". I particularly like
this since we should be able to provide a *very* robust solution and
go on to implement the rest of the linker. There are a few
complications:

• A library cannot know what command line options the program it is in takes.
• There are big restrictions to using fork and threads. For posix, I think the best we can do is provide a function that

calls fork only (not exec) and is documented to do so. It is part of
its contract that it cannot be called with threads active. In a
program that wants to use multiple threads and call it, it should
setup a zygote for calling it (and we can provide code to help it do
so).

Any ideas on how to do this on windows?

C) Similar to A, but use a handler that either call exit or throws if
exceptions are enabled. This would still add a *lot* of checks, but I
don't think the error handling would degrade the code as much. This
means that lld the program would be built without exceptions, but lld
the library would require it. Like A I would ask that this be delayed
until more of the linker is done.

Cheers,
Rafael

[davide]

Not sure if this will go anywhere, and I'm cleaning up my queue. Feel free to add me again things move.

ELF/Driver.h

 #include "llvm/ADT/StringRef.h"
 #include "llvm/Option/ArgList.h"
 
 namespace lld {
 namespace elf2 {
 
 extern class LinkerDriver *Driver;
 
-// Entry point of the ELF linker.
-void link(ArrayRef<const char *> Args);
+// An entry point of the ELF linker. It is not guranteed that the
+// function will return.
+void linkOrFail(ArrayRef<const char *> Args);
+
+// The other entry point of the ELF linker which is guaranteed to return.
+bool link(llvm::ArrayRef<const char *> Args, raw_ostream &Diag);
 
 class LinkerDriver {
 public:
   void main(ArrayRef<const char *> Args);
   void addFile(StringRef Path);
 
 private:
   void readConfigs(llvm::opt::InputArgList &Args);
   void createFiles(llvm::opt::InputArgList &Args);
   template <class ELFT> void link(llvm::opt::InputArgList &Args);
 

ELF/Driver.cpp

 using namespace llvm::object;
 
 using namespace lld;
 using namespace lld::elf2;
 
 Configuration *elf2::Config;
 LinkerDriver *elf2::Driver;
 
-void elf2::link(ArrayRef<const char *> Args) {
+void elf2::linkOrFail(ArrayRef<const char *> Args) {
   Configuration C;
   LinkerDriver D;
   Config = &C;
   Driver = &D;
   Driver->main(Args.slice(1));
 }
 
 static std::pair<ELFKind, uint16_t> parseEmulation(StringRef S) {

ELF/DriverUtils.cpp

 //===----------------------------------------------------------------------===//
 
 #include "Driver.h"
 #include "Error.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
 #include "llvm/Support/StringSaver.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace llvm;
 
 using namespace lld;
 using namespace lld::elf2;
 
 // Create OptTable
 

 std::string elf2::buildSysrootedPath(StringRef Dir, StringRef File) {
   SmallString<128> Path;
   if (Dir.startswith("="))
     sys::path::append(Path, Config->Sysroot, Dir.substr(1), File);
   else
     sys::path::append(Path, Dir, File);
   return Path.str();
 }
+
+// Returns LLD's path on the file system.
+static ErrorOr<std::string> getLldExecutable(StringRef Arg0) {
+  // First, look for "lld" from the current executable directory.
+  // (P just needs to be some symbol in the binary.)
+  void *P = (void *)(intptr_t)getLldExecutable;
+  SmallString<128> Dir;
+  Dir = sys::fs::getMainExecutable(Arg0.data(), &P);
+  sys::path::remove_filename(Dir);
+  if (ErrorOr<std::string> S = sys::findProgramByName("lld", {Dir}))
+    return S;
+
+  // If not found, look for "lld" from $PATH.
+  return sys::findProgramByName("lld");
+}
+
+// This is a wrapper for linkOrFail(). Unlike linkOrFail(),
+// this function always returns.
+bool elf2::link(ArrayRef<const char *> Args, raw_ostream &Diag) {
+  // "-lld-no-exec" is the marker that we are in a subprocess.
+  if (Args.size() > 1 && Args[1] == StringRef("-lld-no-exec")) {
+    std::vector<const char *> Argv(Args.begin(), Args.end());
+    Argv.erase(Argv.begin() + 1);
+    linkOrFail(Argv);
+    exit(0);
+  }
+
+  // We want to build arguments such that lld -flavor gnu Args[1]...
+  ErrorOr<std::string> ExeOrErr = getLldExecutable(Args[0]);
+  if (!ExeOrErr) {
+    Diag << "lld is not found\n";
+    return false;
+  }
+  const char *Exe = ExeOrErr->data();
+  std::vector<const char *> Argv = {Exe, "-flavor", "gnu", "-lld-no-exec"};
+  Argv.insert(Argv.end(), Args.begin() + 1, Args.end());
+  Argv.push_back(nullptr);
+
+  // Start a subprocess and return its result.
+  std::string ErrMsg;
+  int Status =
+      sys::ExecuteAndWait(Exe, Argv.data(), nullptr, nullptr, 0, 0, &ErrMsg);
+  Diag << ErrMsg;
+  return !Status;
+}

include/lld/Driver/Driver.h

 };
 
 /// Driver for Windows 'link.exe' command line options
 namespace coff {
 void link(llvm::ArrayRef<const char *> args);
 }
 
 namespace elf2 {
-void link(llvm::ArrayRef<const char *> args);
+// An entry point for the internal use. It is not guaranteed to return.
+void linkOrFail(llvm::ArrayRef<const char *> args);
+
+// If you want to call LLD ELF's main from your program, use this function.
+// It is guaranteed to return. Returns true on success.
+bool link(llvm::ArrayRef<const char *> args, raw_ostream &diag = llvm::errs());
 }
 
 /// Driver for lld unit tests
 class CoreDriver : public Driver {
 public:
   /// Parses command line arguments same as lld-core and performs link.
   /// Returns true iff there was an error.
   static bool link(llvm::ArrayRef<const char *> args,

lib/Driver/UniversalDriver.cpp

bool UniversalDriver::link(llvm::MutableArrayRef<const char *> args,
 
   Flavor flavor = getFlavor(args, parsedArgs);
 
   // Switch to appropriate driver.
   switch (flavor) {
   case Flavor::old_gnu_ld:
     return GnuLdDriver::linkELF(args, diagnostics);
   case Flavor::gnu_ld:
-    elf2::link(args);
+    elf2::linkOrFail(args);
     return true;
   case Flavor::darwin_ld:
     return DarwinLdDriver::linkMachO(args, diagnostics);
   case Flavor::win_link:
     coff::link(args);
     return true;
   case Flavor::core:
     return CoreDriver::link(args, diagnostics);