<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 14, 2017 at 8:56 AM, Rafael Avila de Espindola <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 class="">Joerg Sonnenberger via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
<br>
> joerg added a comment.<br>
><br>
> I really dislike this direction. fallocate can double the amount of disk IO and increase cache trashing, especially when linking large programs with debug information. Keeping more things in memory doesn't sound like an actual improvement either. If the goal is really only to improve the diagnostics in tools, I think a better idea would be to figure out a good way to handle this from a SIGBUS handler based on the passed in siginfo_t.<br>
<br>
</span>fallocate is really fast on modern filesystems.<br>
<br>
I really don't want to get lld into the business of handling SIGBUS.<br></blockquote><div><br></div><div>I'd agree with that. Especially when you are using lld as a library, we shouldn't change the signal handler, but we still want to catch disk full errors.</div></div></div></div>