<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Rui<div class=""><br class=""></div><div class="">I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very involved discussion about what it means to be a library. Specifically, I don't think your current 'main-as-library' argument is valid while you call exit or (if you) rely on mutable global state. Having a single entry point via a main function is fine, but that function cannot then kill the process which its linked in to.</div><div class=""><br class=""></div><div class="">If you want context then the relevant piece of the thread is <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html</a>.</div><div class=""><br class=""></div><div class="">Arseny summarized things very well there, so i'll just quote him at the end here. I understand that you and others want to first write a fast linker tool and i don't think anyone has any problem with that, but there is also a clear desire from folks to have it be usable as a library and I would hope any patches to do so are accepted, even if they make the code more complex, or slower.</div><div class=""><br class=""></div><div class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">>>><i class=""> On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev <
</i>>>><i class=""> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="">llvm-dev at lists.llvm.org</a>> wrote:
</i>>>><i class="">
</i>>>>><i class=""> In the process of migrating from old lld ELF linker to new (previously
</i>>>>><i class=""> ELF2) I noticed the interface lost several important features (ordered by
</i>>>>><i class=""> importance for my use case):
</i>>>>><i class="">
</i>>>>><i class=""> 1. Detecting errors in the first place. New linker seems to call
</i>>>>><i class=""> exit(1) for any error.
</i>>>>><i class="">
</i>>>>><i class=""> 2. Reporting messages to non-stderr outputs. Previously all link
</i>>>>><i class=""> functions had a raw_ostream argument so it was possible to delay the error
</i>>>>><i class=""> output, aggregate it for multiple linked files, output via a different
</i>>>>><i class=""> format, etc.
</i>>>>><i class="">
</i>>>>><i class=""> 3. Linking multiple outputs in parallel (useful for test drivers) in a
</i>>>>><i class=""> single process. Not really an interface issue but there are at least two
</i>>>>><i class=""> global pointers (Config & Driver) that refer to stack variables and are
</i>>>>><i class=""> used in various places in the code.
</i>>>>><i class="">
</i>>>>><i class=""> All of this seems to indicate a departure from the linker being useable
</i>>>>><i class=""> as a library. To maintain the previous behavior you'd have to use a linker
</i>>>>><i class=""> binary & popen.</i></pre><div class="">Pete</div></div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 16, 2016, at 10:15 AM, Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I talked several people and found that this is more like a communication issue rather than a technical/philosophical issue. I believe communication problems won't solve themselves. As a person who is on the owners file of LLD, I think I need to say something about that issue. Also, I guess people who were just watching this thread wondered why my happy pre-holiday status report suddenly turned into a heated discussion, and they are probably still wondering what's wrong with LLD. I want to address that, too.</div><div class=""><br class=""></div><div class="">So, as a project, there is no anti-library policy in LLD. I think this is the misunderstanding one side had. We already provide main-as-a-library feature so that you can embed the linker to your program. We as a project welcome other ideas to export linker features at a well-defined boundary. For example, I think abstracting the file system access so that you can hook file operations could be a well-defined, useful API for those who want to do in-memory linking (I expressed that opinion already in this thread). Just like LLVM, we won't guarantee API compatibility between releases, and we are unlikely to be able to expose deep internals of the linker, but as long as you think you found a reasonable coarse API boundary, there should be nothing preventing you from bringing that to the table.</div><div class=""><br class=""></div><div class="">On the other hand, as far as I talked, no one who is on the "library" side requested LLD expose deep internals. This is the misunderstanding the other side had. If we as a project said that LLD should not support any library interface at all, they would be upset and speak out loudly, but again, that's not a project policy.</div><div class=""><br class=""></div><div class="">So, correct me if I'm wrong, but I don't see no serious conflicts here. The conflict I saw in the thread is I believe superficial, and I strongly believe that it could have been addressed calmly and nicely if we have used more words to explain thoughts instead of small number of strong words.</div><div class=""><br class=""></div><div class="">Hope this helps.</div><div class=""><br class=""></div><div class="">Rui</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Dec 16, 2016 at 1:40 AM, George Rimar via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>I am on PTO, so slow to respond.<br class="">
><br class="">
>Some items that are left:<br class="">
><br class="">
>* Debug fission<br class="">
>* Single file debug fission<br class="">
>* Range extension thunks<br class="">
>* All of freebsd links and works<br class="">
>* Very good performance when all that is in<br class="">
<br class="">
</span>Looks we have initial version of debug fusion implemented.<br class="">
r289790, r289810 commits from yesterday did the rest of main job I believe.<br class="">
I do not know what is "Single file debug fission" ? (quick googling gives nothing and I never heard about that before I think)<br class="">
<br class="">
George.<br class="">
<div class="HOEnZb"><div class="h5">______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>