<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 1:33 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><br><hr id="m_-736384679209664994zwchr"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Rui Ueyama" <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>><br><b>To: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br><b>Cc: </b>"Rafael Avila de Espindola" <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>>, "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "Andrew Kelley" <<a href="mailto:superjoe30@gmail.com" target="_blank">superjoe30@gmail.com</a>><br><b>Sent: </b>Tuesday, December 13, 2016 3:08:15 PM<div><div class="h5"><br><b>Subject: </b>Re: [llvm-dev] LLD status update and performance chart<br><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 13, 2016 at 12:40 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote id="m_-736384679209664994DWT29790" class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>----- Original Message -----<br>
> From: "Rafael Avila de Espindola via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> To: "Andrew Kelley" <<a href="mailto:superjoe30@gmail.com" target="_blank">superjoe30@gmail.com</a>>, "Rui Ueyama" <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>><br>
> Cc: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
</span><span>> Sent: Tuesday, December 13, 2016 2:30:41 PM<br>
> Subject: Re: [llvm-dev] LLD status update and performance chart<br>
><br>
</span><div><div class="m_-736384679209664994h5">> Andrew Kelley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
><br>
> > On Tue, Dec 13, 2016 at 1:06 PM, Rui Ueyama via llvm-dev <<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >><br>
> >> That said, I think the current our "API" to allow users call our<br>
> >> linker's<br>
> >> main function hit the sweet spot. I know at least a few LLVM-based<br>
> >> language<br>
> >> developers who want to eliminate external dependencies and embed a<br>
> >> linker<br>
> >> to their compilers. That's a reasonable usage, and I think<br>
> >> allowing them to<br>
> >> pass a map from filename to MemoryBuffer objects makes sense, too.<br>
> >> That<br>
> >> would be done without affecting the overall linker architecture. I<br>
> >> don't<br>
> >> oppose to that idea, and if someone wrote a patch, I'm fine with<br>
> >> that.<br>
> >><br>
> ><br>
> > As an LLVM-based language developer, this is exactly what I want to<br>
> > do. In<br>
> > short:<br>
> ><br>
> >  * Avoid depending on an external binary<br>
> >  * Avoid a fork+exec<br>
> >  * Avoid unnecessary use of the filesystem<br>
> ><br>
> > Does this feature compromise progress on the linker binary?<br>
> ><br>
> > Would it be reasonable for this feature to exist in the next minor<br>
> > version<br>
> > release of lld?<br>
><br>
> I would please ask for it to wait. It requires designing how the<br>
> linker<br>
> script parser and the thin archive system will fetch new files as<br>
> they<br>
> are found.<br>
<br>
</div></div>Instead of just waiting, I think we should discuss design requirements. Clang, for example, has a VFS layer too (in include/clang/Basic/<wbr>VirtualFileSystem.h) which seems independent from Clang. Maybe we want to move it into LLVM and reuse it from both Clang and LLD. Would this VFS layer meet the requirements for an LLD VFS layer too?</blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div><br></div><div id="m_-736384679209664994DWT29791">Sorry my negligence, but what does Clang VFS layer provide? Looking at the header file, it looks to me that it provides functionalities to hook all file operations, so that you can run Clang against, well, a virtual file system that may not exist as a OS-level file system at all, for example. Is my understanding correct?</div></div></div></div></div></div></blockquote>Yes, I believe that is correct.</div></div></blockquote><div><br></div><div>I took a look a bit more closely at the VFS layer. I can imagine that a few reasonable use cases of the abstraction. One is obviously what Andrew wants -- in-memory linking. That would be useful for distributed build system too. (You can virtualize a file system using fuse, but that's not cross-platform.)</div><div><br></div><div>I don't remember who said that, but someone proposed me if LLD can support something like a "linker-driven build system", in which objects are created when a linker needs them. It is experimental so it wouldn't need a support in the main trunk, but a virtual filesystem would allow such system.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><span class=""><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div id="m_-736384679209664994DWT29792">As to a JIT linker, I once wrote a small JIT C compiler which creates an object file in memory and then jump to the entry point of the file after relocating it in memory. From that experience (and my experience of LLD), I'd think JIT linker is much easier to write than static linkers, because JIT linkers don't need to interact with dynamic linkers. Static linkers have to create data that will be interpreted by the dynamic linker, and that's one of the most complicated things in LLD (the other is the linker script, but that's a different story.) So I don't expect that there are many things that we can share between JIT linkers and static linkers. Of course there may be something that I don't know well about JIT, but that's my feeling at this moment.</div></div></div></div></blockquote></span>Right now, both parts of LLVM have code to process relocations, produces PLTs, etc. Those are target-specific things and it would be nice not to have to code them twice. Obviously, I could be oversimplifying the situation.<span class="HOEnZb"><font color="#888888"><br><br> -Hal</font></span><span class=""><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-736384679209664994HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><span class="m_-736384679209664994im m_-736384679209664994HOEnZb"><br>
><br>
> Also, please consider what is so bad about writing a file. If your<br>
> language has anything like translation unites than most of the<br>
> program<br>
> should already be in .o files.<br>
><br>
> Cheers,<br>
> Rafael<br>
</span><span class="m_-736384679209664994im m_-736384679209664994HOEnZb">> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
><br>
<br>
</span><div class="m_-736384679209664994HOEnZb"><div class="m_-736384679209664994h5">--<br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></span></div></div></blockquote></div><br></div></div>