<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 7, 2016, at 3:59 PM, Arseny Kapoulkine 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="">> <span style="font-size:12.8px" class="">Why do you want to use that as a library? I don't think "because LLVM and Clang allow that" is not a compelling argument since the linker and the compiler are pretty different programs. I clearly see many reasons to use LLVM and part of Clang as libraries, but they are not directly applicable to LLD. The new linker is more like a command which is built on top of the libraries that LLVM provides.</span><div class="" style="font-size:12.8px"></div><div class="" style="font-size:12.8px"><br class=""></div><div class="" style="font-size:12.8px">My specific use-case is that of a compiler with an in-process linker that also runs tests (like Eric mentioned) - so basically a complete ahead-of-time compilation suite in a single process. In my case I *think* it's not prohibitively expensive to invoke a process - it complicates things but does not make them impossible. I started down this path because LLVM and lld allowed that. I had some plans that involved using similar infrastructure in a JIT-like manner (e.g. a REPL that would link the binary and load it), but this is probably better served using the actual JIT.</div><div class="" style="font-size:12.8px"><br class=""></div><div class="" style="font-size:12.8px">I think there are environments where invoking a process or exit(1)-ing is absolutely prohibitive. I personally can solve these issues by fork/exec-ing the driver to perfom linking, but I don't quite understand how AMDGPU target can be useful in the new ELF linker since I had the impression that AMD basically uses ELF for the shader binary format, and compilation has to happen inside OpenGL driver (where you *want* to run shader compilation from multiple threads and definitely don't want a linking issue to exit the process in case of a user-mode driver).</div></div></div></blockquote><div><br class=""></div><div>Usually you create a new process anyway when integrating within a driver to shield a crash from the compiler linker from the rest of the stack, the same way the clang driver does (usually) issue a new process for the compilation.</div><div>(this is not an argument against the library design, which I completely support).</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="" style="font-size:12.8px"><br class=""></div><div class="" style="font-size:12.8px">Arseny</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jan 7, 2016 at 9:06 AM, Rui Ueyama <span dir="ltr" class=""><<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Designing it a command makes things simpler because you can safely assume that most functions always success, or otherwise the entire process terminates. You can defer the operating system to clean up all resources that was used by the process however it fails (with a few exceptions such as temporary files.) I actually like to use the linker as an external command since the operating system provides good isolation between my process and the linker which could fail by an unknown bug or something. Rewriting all of them as functions that return ErrorOr<Something> is technically doable, but it needs strong justification, so I guess that unlikely to change.<div class=""><br class=""></div><div class="">Why do you want to use that as a library? I don't think "because LLVM and Clang allow that" is not a compelling argument since the linker and the compiler are pretty different programs. I clearly see many reasons to use LLVM and part of Clang as libraries, but they are not directly applicable to LLD. The new linker is more like a command which is built on top of the libraries that LLVM provides.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jan 7, 2016 at 8:28 AM, Arseny Kapoulkine <span dir="ltr" class=""><<a href="mailto:arseny.kapoulkine@gmail.com" target="_blank" class="">arseny.kapoulkine@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">This is really unfortunate.<div class=""><br class=""></div><div class="">I've read the discussion threads for the atom/chunk controversy and I feel like I understand the reasons for rewriting the linker, but this does not seem to have anything to do with whether the linker is usable as a library or not.</div><div class=""><br class=""></div><div class="">As it stands, not only does lld have two completely different linkers (I'm treating COFF/ELF2 as one since they are really two different implementations of the same concept, AFAIU), but one is usable as a library (and even does not require round-tripping generated code through an object file! I was really happy to use that) and the other one isn't. Not sure what the future plans are for Mach-O linker (at this point it seems logical to rewrite that using the new designs but I'm not sure if it ever happens), so maybe at some point we'll just have one linker application instead of a library and an application.</div><div class=""><br class=""></div><div class="">Anyway, since linker is the only missing piece for full compilation stack (source language to runnable executable), it's sad to see this specific part of LLVM not working as a library when everything else does.</div><div class=""><br class=""></div><div class="">Are there specific concerns in terms of implementation that prevent new lld from being a library? I understand that using global variables and error() function is simpler, but the rest of LLVM does not do that and the codebase there is significantly larger. Am I missing any other issues except for the ones I mentioned in my original e-mail that will come up in a library-like usage scenario?</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Arseny</div></font></span></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jan 7, 2016 at 7:17 AM, Rui Ueyama <span dir="ltr" class=""><<a href="mailto:ruiu@google.com" target="_blank" class="">ruiu@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><span class=""><div class="gmail_extra">On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine 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=""></div></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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" class="">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 class=""><br class=""></div><div class=""><div class="">1. Detecting errors in the first place. New linker seems to call exit(1) for any error.</div></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Is this a conscious design decision or a temporary limitation?</div></div></blockquote><div class=""><br class=""></div></span><div class="">That the new ELF and COFF linkers are designed as commands instead of libraries is very much an intended design change.</div><span class=""><div class=""> </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" class=""><div class="">If it's a limitation, how would one go about fixing this? I'm not too familiar with the idiomatical error handling in LLVM. Normally in this situation I'd just throw from error() but lld is probably compiled without exceptions. Is ErrorOr the established practice? How does LLVM generally deal with error handling for parsers (like linker script parser) where it's a lot of mutually recursive functions where every single one can fail?</div></div></blockquote><div class=""><br class=""></div></span><div class="">Since it's as designed, please run the linker as an external command using fork/exec (or wrappers of them) instead of trying to use that inside the same process.</div><div class=""><br class=""></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" class=""><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Arseny</div></font></span></div>
<br class="">_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" 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/mailman/listinfo/llvm-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
</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=""></body></html>