<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 23, 2017 at 9:49 PM, Andrew Kelley 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class=""><div>...</div></span></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div style="color:rgb(80,0,80);font-size:12.8px">It's starting to look to me like that might be necessary to integrate with LLD, if I want to handle this SIGBUS error. I'd like to handle out of disk space gracefully and not crash.</div><div style="color:rgb(80,0,80);font-size:12.8px"><br></div></div></div></div></div></blockquote><div><br></div><div>It seems to me like command-line-lld should behave this way also.  Though I can appreciate the convenience and benefits of mmap() over write().  And I would expect the performance impact of posix_fallocate() could be significant on some filesystems, as Rui indicates.  It's too bad there's no interface to put it in the background and find out its progress other than "gee, what happens if we touch this page?"</div><div><br></div><div>Would it make any sense to amortize the expense over multiple posix_fallocate() calls?  Just posix_fallocate() enough to hit whatever offset we're using into the mmap plus the size of the write (rounded up to the next block).  I suppose it's a relatively inexpensive call if we've already allocated enough space.  If the posix_fallocate() fails we can gracefully report the disk space exhaustion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div style="color:rgb(80,0,80);font-size:12.8px"></div><div style="color:rgb(80,0,80);font-size:12.8px">Here are my concerns:</div><div style="color:rgb(80,0,80);font-size:12.8px"><br></div><div style="color:rgb(80,0,80);font-size:12.8px"> * My frontend is cross-platform, so I would also need to figure out how this would work on Windows, and eventually on other OSes too. Installation of my frontend is simpler if there is not more than 1 executable to distribute.</div><div style="color:rgb(80,0,80);font-size:12.8px"> * This isn't working right now, but I want the errors of linking to provide meaningful error codes and other metadata in a format the frontend can associate with  its own state and and handle/render the errors in its own way. If this is done via IPC it has to go through a serialization/deserialization step.</div><div style="color:rgb(80,0,80);font-size:12.8px"> * One of the use cases for my frontend is as a server where it may invoke the linker repeatedly. I haven't tested the difference in performance or resource usage yet, but it seems to me that LLD as a library / no forking would be more efficient.</div><div style="color:rgb(80,0,80);font-size:12.8px"> * I would rather compile against LLVM  and clang statically for performance and ease of installation (at least on Windows). If LLD is a separate binary it would additionally need LLVM/Clang linked in statically, and this is a duplicate copy of LLVM/Clang, doubling the size of my compiler releases. Further the LLVM initialization code can be shared between my frontend and LLD when linked into the same binary.</div><div><br></div><span style="color:rgb(80,0,80);font-size:12.8px"></span></div><span class=""><div> </div></span></div></div></div></blockquote><div> </div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">-Brian</div>
</div></div>