<div dir="rtl"><div dir="ltr">On Windows fork() is not available. If exec() is used instead, process creation time is several times slower than Linux. This may be or not a problem dependeing on how lld is used. In general, on Windows the best solution is multi-threading.</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div dir="ltr">2016-01-22 18:31 GMT+02:00 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>:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think I have an idea to cover your need and possibly other people's on this thread. It provides the "main() as a library function" feature, input/output files wouldn't go through disks nor file systems, and it doesn't require any major design changes. Sounds too good?<div><br></div><div>That is, we can provide a function that takes command line parameters, do fork, and call the linker's main function.</div><div><br></div><div>This may sound too simple, but I think that is fairly powerful. Because the child process has a copy(-on-write) of the parent's memory, it can read parent's in-memory object files directly with no overhead. The child can pass the resulting file back to the parent through a shared memory object (which we can obtain using shm_open or something like that). In addition to that, your main process gets a protection from linker's bugs thanks to the operating system's memory protection. But from the user's point of view, that is just a linker's main function that you can call and that works as expected.</div><div><br></div><div>Even if we want to call exec for whatever reason, we can copy in-memory objects to shared memory objects and exec the linker, so the basic design should work in such case too.</div><div><br></div><div>The function signature would be something like:</div><div><br></div><div>  bool link(ArrayRef<LinkerArg> CommandLineArgs, MemoryBuffer &OutputFile, std::string &ErrorMsg);</div><div><br></div><div>where the return value indicates success/failure. LinkerArg is a union type of StringRef and MemoryBufferRef. The result is returned as OutputFile memory buffer. If it prints out any message, ErrorMsg will hold it.</div><div><br></div><div>(I want to point out that the function "<span style="font-size:12.8px">bool link(ArrayRef<const char*> args, raw_ostream& diagnostics, ArrayRef<unique_ptr<</span><span style="font-size:12.8px">MemoryBuffer>> inputs)" doesn't work because the order of command line parameters matters. Some command line parameters, such as --whole-archive/--no-whole-archive, affects how files in between will be interpreted, so you can't separate command line parameters from a list of files.)</span></div><div><br></div><div>I think this is a practical solution that we can do now. I can implement this for you.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 9:28 PM, Arseny Kapoulkine <span dir="ltr"><<a href="mailto:arseny.kapoulkine@gmail.com" target="_blank">arseny.kapoulkine@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"><span>> <span style="font-size:12.8px">In any case, I have simply wasted too much time on a thread with someone with no patches on the new elf linker. It is really annoying that you don't put effort into it and seem entitled to dictate its direction.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Sorry about that. I was initially planning to work on a patch to enhance the interface for new lld - hence my questions in the original post. Since I learned that people writing the code for lld are hostile to the idea of linker-as-a-library, error_code is treated as spaghetti (which would be fine if LLVM used exceptions which it does not) and patches, even if submitted, will not actually be reviewed in a timely manner, I'll try to adapt my code to either not use lld or use lld-as-a-binary.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I'm disappointed by all of this but obviously it's not my project so I should not have a say in this.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thank you for your time.</span></div><span><font color="#888888"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Arseny</span></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 8:44 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><p dir="ltr">> Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way.</p>
</span><p dir="ltr">Then go change clang and send a patch for lld once you are done. It will be interested to see if you can measure a single fork in an entire build.</p>
<p dir="ltr">Even better, please finish the new pass manager before working on clang forking cc1.</p>
<p dir="ltr">In any case, I have simply wasted too much time on a thread with someone with no patches on the new elf linker. It is really annoying that you don't put effort into it and seem entitled to dictate its direction.</p>
<p dir="ltr">If you want to kick us out of the llvm project, please start a thread on llvm-dev.</p>
<p dir="ltr">If you want lld to be a library, figure out how to do it without sacrificing lld's productivity,  error reporting and performance (no error_code spaghetti) and write a patch. Just don't expect it to be reviewed while we have actual missing features.</p>
<p dir="ltr">I will go back to implementing the linker.</p><span><font color="#888888">
<p dir="ltr">Rafael</p>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</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>