<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 18, 2016 at 7:21 AM, Rafael Avila de Espindola 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:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
<br>
> So, as a project, there is no anti-library policy in LLD. I think this is<br>
> the misunderstanding one side had. We already provide main-as-a-library<br>
> feature so that you can embed the linker to your program. We as a project<br>
> welcome other ideas to export linker features at a well-defined boundary.<br>
> For example, I think abstracting the file system access so that you can<br>
> hook file operations could be a well-defined, useful API for those who want<br>
> to do in-memory linking (I expressed that opinion already in this thread).<br>
> Just like LLVM, we won't guarantee API compatibility between releases, and<br>
> we are unlikely to be able to expose deep internals of the linker, but as<br>
> long as you think you found a reasonable coarse API boundary, there should<br>
> be nothing preventing you from bringing that to the table.<br>
<br>
</span>It really depends on what is meant by a library.<br>
<br>
If we have to remove all calls to exit, all memory pools and all global<br>
variables I am very opposed to it.<br></blockquote><div><br></div><div>It would depend. If there was a *really* compelling use case it might be worth it.</div><div><br></div><div>I think what you're saying is basically: the linker is currently much simpler and easier to maintain due to the fatal errors on corrupted input, globals for the "context", etc.</div><div>We need a compelling use case to give that up, and nothing sufficiently compelling has been presented. And currently the focus is on feature parity with existing linkers and systems, so naturally we aren't exploring tons of new use cases unless our users come to us with requests.</div><div><br></div><div>In fact, I would say that as we've implemented the linker and as a community of LLD developers learned more about linkers, many of the theoretical use cases seem less realistic than before.</div><div><br></div><div>We're still doing some of the things that the LLD originally set out to do. For example, LLD/ELF has grown color diagnostics and will dig through DWARF to give source locations (it's like one or two function calls into the LLVM libraries to do this, so there's nothing left to "factor out" from LLD/ELF itself).<br></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
lld is an actual project with actual value for its users. I really don't<br>
want to compromise its maintainability by turning every<br>
<br>
for (auto &X : check(...))<br>
<br>
into<br>
<br>
auto XsOrErr = ...;<br>
if (std::error_code EC = XsOrErr.getError())<br>
  return EC; // also update callers. Add more context to the return if<br>
             // you don't want to degrade the error message.<br>
auto &Xs = *XsOrErr;<br>
for (auto &X : Xs)<br>
<br>
In the name of a theoretical user. Really, can we put this on hold<br>
until the MachO linker has shown how to get its parts actually reused?<br>
<br>
Cheers,<br>
Rafael<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>