<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 21, 2016 at 10:49 AM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> There are probably others, but this is the gist of it. Now, you could still<br>
> design everything with the simplest imaginable API, that is incredibly<br>
> narrow and specialized for a *single* user. But there are still fundamentals<br>
> of the style of code that are absolutely necessary to build a library. And<br>
> the only way to make sure we get this right, is to have the single user of<br>
> the code use it as a library and keep all the business logic inside the<br>
> library.<br>
><br>
> This pattern is fundamental to literally every part of LLVM, including<br>
> Clang, LLDB, and thus far LLD. I think it is a core principle of the project<br>
> as a whole. I think that unless LLD continues to follow this principle, it<br>
> doesn't really fit in the LLVM project at all.<br>
<br>
The single user so far is the one the people actually coding the<br>
project care for. I seems odd to say that it doesn't fit in the LLVM<br>
project when it has attracted a lot of contributors and hit some<br>
important milestones.<br></blockquote><div><br></div><div>I don't think that every open source effort relating to compilers belongs in the LLVM project. I think that they would have to fit with the overarching goals and design of the LLVM project as a whole. This includes, among other things, being modular and reusable.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> So, I encourage LLD to keep its interfaces highly specialized for the users<br>
> it actually has -- and indeed today that may be exactly one user, the<br>
> command line linker.<br>
<br>
We have a highly specialized api consisting of one function:<br>
elf2::link(ArrayRef<const char *> Args). That fits 100% of the uses we<br>
have. If there is ever another use we can evaluate the cost of<br>
supporting it, but first we need to actually write the linker.<br></blockquote><div><br></div><div>Note that I'm perfectly happy with this *interface* today, provided it is genuinely built as a library and can be used in that context. See below.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Note that this is history replaying itself in a bigger scale. We used<br>
to have a fancy library to handle archives and llvm-ar was written on<br>
top of it. It was the worst ar implementation by far. It had horrible<br>
error handling, incompatible options and produced ar files with<br>
indexes that no linker could use.<br>
<br>
I nuked the library and wrote llvm-ar as the trivial program that it<br>
is. To the best of my knowledge it was then the fastest ar in<br>
existence, actually useful (linkers can use it's .a files) and far<br>
easier to maintain.<br></blockquote><div><br></div><div>The fact that it was in a library, IMO, is completely orthogonal from the fact that the design of that library ended up not working.</div><div><br></div><div>Bad library code is indeed bad. That doesn't mean that it is terrible hard to write good library code, as you say:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When the effort to support windows came up, there was a need to create<br>
archives from within lld since link.exe can run lib.exe. The<br>
maintainable code was easy to refactor into one library function<br>
llvm::writeArchive. If another use ever show up, we evaluate it. If<br>
not, we keep the very narrow interface.<br></blockquote><div><br></div><div>Yes, +1 to narrow interface, but I think it should always be *in a library*. That impacts much more than just the interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Finally, I will directly state that we (Google) have a specific interest in<br>
> both linking LLD libraries into the Clang executable rather than having<br>
> separate binaries, and in invoking LLD to link many different executables<br>
> from a single process. So there is at least one concrete user here today.<br>
> Now, the API we would need for both of these is *exactly* the API that the<br>
> existing command line linker would need. But the functionality would have to<br>
> be reasonable to access via a library call.<br>
<br>
Given that clang can fork, I assume that this new clang+lld can fork.<br></blockquote><div><br></div><div>No, it cannot in all cases. We have genuine use cases where forking isn't realistically an option. As an example, imagine that you want to use something like ClangMR (which I presented ages ago) but actually *link* code massively at scale to do post-link analysis of the binaries? There are environments where we need to be able to run the linker on multiple different threads in a single address space and collect the linked object in an in-memory buffer.</div><div><br></div><div>Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way.</div></div></div>