[llvm-dev] lld: ELF/COFF main() interface

[Rafael Espíndola via llvm-dev]

> There are probably others, but this is the gist of it. Now, you could still
> design everything with the simplest imaginable API, that is incredibly
> narrow and specialized for a *single* user. But there are still fundamentals
> of the style of code that are absolutely necessary to build a library. And
> the only way to make sure we get this right, is to have the single user of
> the code use it as a library and keep all the business logic inside the
> library.
>
> This pattern is fundamental to literally every part of LLVM, including
> Clang, LLDB, and thus far LLD. I think it is a core principle of the project
> as a whole. I think that unless LLD continues to follow this principle, it
> doesn't really fit in the LLVM project at all.

The single user so far is the one the people actually coding the
project care for. I seems odd to say that it doesn't fit in the LLVM
project when it has attracted a lot of contributors and hit some
important milestones.

> So, I encourage LLD to keep its interfaces highly specialized for the users
> it actually has -- and indeed today that may be exactly one user, the
> command line linker.

We have a highly specialized api consisting of one function:
elf2::link(ArrayRef<const char *> Args). That fits 100% of the uses we
have. If there is ever another use we can evaluate the cost of
supporting it, but first we need to actually write the linker.

Note that this is history replaying itself in a bigger scale. We used
to have a fancy library to handle archives and llvm-ar was written on
top of it. It was the worst ar implementation by far. It had horrible
error handling, incompatible options and produced ar files with
indexes that no linker could use.

I nuked the library and wrote llvm-ar as the trivial program that it
is. To the best of my knowledge it was then the fastest ar in
existence, actually useful (linkers can use it's .a files) and far
easier to maintain.

When the effort to support windows came up, there was a need to create
archives from within lld since link.exe can run lib.exe. The
maintainable code was easy to refactor into one library function
llvm::writeArchive. If another use ever show up, we evaluate it. If
not, we keep the very narrow interface.

> Finally, I will directly state that we (Google) have a specific interest in
> both linking LLD libraries into the Clang executable rather than having
> separate binaries, and in invoking LLD to link many different executables
> from a single process. So there is at least one concrete user here today.
> Now, the API we would need for both of these is *exactly* the API that the
> existing command line linker would need. But the functionality would have to
> be reasonable to access via a library call.

Given that clang can fork, I assume that this new clang+lld can fork.
If so, you might actually already be able to do it, just call
elf2::link(ArrayRef<const char *> Args) in a new process. It is
guaranteed to not crash your program or leak resources (short of a
kernel bug).

Cheers,
Rafael