<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 7, 2016 at 3:17 PM, Rui Ueyama 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><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"><div class="gmail_extra"><div class="gmail_quote"><span class="">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: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"><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: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"><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></span><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. The new one is designed as a command from day one.</div></div></div></div></blockquote><div><br></div><div><div>My recollection is that the plan was to basically factor out of COFF/ELF2 and into LLVM whenever we saw the need to share functionality (not just between COFF and ELF2, or with MCJIT, but in general).</div><div><br></div><div>I guess the question is whether eventually enough stuff will be factored out into libraries that we will have a coherent set of reusable "linker libraries" (in which case it might make sense to pull those out of LLVM and into lld/{include,lib}) and the COFF/ELF2 command line programs will naturally become "thin wrappers around the library code".</div><div><br></div><div>At this point it is unclear (to me, at least) whether that will happen or not. If not, then in order to meet the use case of linker functionality in a library, we will have to take the command line programs and do some straightforward transformations to get a "main() in a library"  type interface (MemoryBuffer's instead of filenames, etc.) to meet those use cases.</div></div><div><br></div><div>Of course, the "main() in a library" scenario is a bit depressing and we should avoid it if possible, since it really does go against the whole LLVM philosophy. The atom LLD warned us of the dangers of overgeneralizing/overabstracting important details/specifics that linkers actually have to deal with, so it's natural that COFF/ELF2 is a reaction to this. We just need to make sure that we find the right middle ground and don't get stuck in the opposite extreme that the atom LLD got stuck in. There is a saying that "you have to go too far to know how far is far enough"; I think right now we are exploring the "not a library / not generalized / not abstracted" side of things and will incrementally pull back towards the right middle ground as we gain experience and new and interesting use cases come within reach.</div><div><br></div><div>-- Sean Silva</div><div> </div><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"><div class="gmail_extra"><div class="gmail_quote"><div> (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><span class=""><div><br></div><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"><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></span></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, 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>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>