<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 7, 2016 at 3:18 PM Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 7, 2016 at 2:56 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">In the process of migrating from old lld ELF linker to new (previously ELF2) I noticed the interface lost several important features (ordered by importance for my use case):<div><br></div><div><div>1. Detecting errors in the first place. New linker seems to call exit(1) for any error.</div></div><div><br></div><div>2. Reporting messages to non-stderr outputs. Previously all link functions had a raw_ostream argument so it was possible to delay the error output, aggregate it for multiple linked files, output via a different format, etc.</div><div><br></div><div>3. Linking multiple outputs in parallel (useful for test drivers) in a single process. Not really an interface issue but there are at least two global pointers (Config & Driver) that refer to stack variables and are used in various places in the code.</div><div><br></div><div>All of this seems to indicate a departure from the linker being useable as a library. To maintain the previous behavior you'd have to use a linker binary & popen.</div><div><br></div><div>Is this a conscious design decision or a temporary limitation?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That the new ELF and COFF linkers are designed as commands instead of libraries is very much an intended design change.</div></div></div></div></blockquote><div><br></div></span><div>I disagree.</div><div><br></div><div>During the discussion, there was a *specific* discussion of both the new COFF port and ELF port continuing to be libraries with a common command line driver.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>There was a discussion that we would keep the same entry point for the old and the new, but I don't remember if I promised that we were going to organize the new linker as a library.</div></div></div></div></blockquote><div><br></div><div>Ok, myself and essentially everyone else thought this was clear. If it isn't lets clarify:</div><div><br></div><div>I think it is absolutely critical and important that LLD's architecture remain one where all functionality is available as a library. This is *the* design goal of LLVM and all of LLVM's infrastructure. This applies just as much to LLD as it does to Clang.</div><div><br></div><div>You say that it isn't compelling to match Clang's design, but in fact it is. You would need an overwhelming argument to *diverge* from Clang's design.</div><div><br></div><div>The fact that it makes the design more challenging is not compelling at all. Yes, building libraries that can be re-used and making the binary calling it equally efficient is more challenging, but that is the express mission of LLVM and every project within it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> The new one is designed as a command from day one. (Precisely speaking, the original code propagates errors all the way up to the entry point, so you can call it and expect it to always return. Rafael introduced error() function later and we now depends on that function does not return.)</div></div></div></div></blockquote><div><br></div><div>I think this last was a mistake.</div><div><br></div><div>The fact that the code propagates errors all the way up is fine, and even good. We don't necessarily need to be able to *recover* from link errors and try some other path.</div><div><br></div><div>But we absolutely need the design to be a *library* that can be embedded into other programs and tools. I can't even begin to count the use cases for this.</div><div><br></div><div>So please, let's go back to where we *do not* rely on never-returning error handling. That is an absolute mistake.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>If you want to consider changing that, we should have a fresh (and broad) discussion, but it goes pretty firmly against the design of the entire LLVM project. I also don't really understand why it would be beneficial.</div></div></div>
</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><br></div><div class="gmail_extra">I'm not against organizing it as a library as long as it does not make things too complicated</div></div></blockquote><div><br></div><div>I am certain that it will make things more complicated, but that is the technical challenge that we must overcome. It will be hard, but I am absolutely confident it is possible to have an elegant library design here. It may not be as simple as a pure command line tool, but it will be *dramatically* more powerful, general, and broadly applicable.</div><div><br></div><div>The design of LLVM is not the simplest way to build a compiler. But it is valuable to all of those working on it precisely because of this flexibility imparted by its library oriented design. This is absolutely not something that we should lose from the linker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">, and I guess reorganizing the existing code as a library is relatively easy because it's still pretty small, but I don't really want to focus on that until it becomes usable as an alternative to GNU ld or gold. I want to focus on the linker features themselves at this moment. Once it's complete, it becomes more clear how to organize it.</div></div></blockquote><div><br></div><div>Ok, now we're talking about something totally reasonable.</div><div><br></div><div>If it is easier for you all to develop this first as a command line tool, and then make it work as a library, sure, go for it. You're doing the work, I can hardly tell you how to go about it. ;]</div><div><br></div><div>However, I think it is super important to be clear that getting the library architecture is a *hard requirement* for the LLD project. Without that, it doesn't even make sense as part of LLVM.</div><div><br></div><div>And as a consequence, I think it is unacceptable to replace the old ELF port with the new one until this is true. That is removing functionality that users of LLD realistically were depending on, which you're seeing in this thread. That's not cool. We don't really tolerate dramatic regressions in functionality like this, and even if we've already done it, we should revert back to a state where both are available until the new port is actually ready. And ready in LLVM land means, functional as a library.</div><div><br></div><div>-Chandler</div></div></div>