<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 1, 2016 at 11:18 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><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">silvas added a subscriber: silvas.<br>
silvas added a comment.<br>
<span><br>
In <a href="http://reviews.llvm.org/D16668#340546" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16668#340546</a>, @rafael wrote:<br>
<br>
> I don't think so.<br>
><br>
> The problem is that we were not at 100% coverage with fatal. There are many cases where we would just follow a broken offset and crash. If we can produce a segmentation fault, we can call fatal.<br>
><br>
> If we cannot produce a segmentation fault, we will need another way of fixing this.<br>
<br>
<br>
</span>I think this does cover the case of programmatic invocation of LLD (i.e., with known-good object files, which seems like the primary use case for programmatic invocation), so it does still seem worth it.<br>
<br>
Bulletproofing against all possible defective object files (i.e. guaranteeing no segfaults) is a huge amount of work I suspect (and probably not worth it?), but this change does seem to cover a real (and requested by many people in the community) use case.<br></blockquote><div><br></div><div>This actually covers more than the case of programmatic invocation of LLD because my patches converted some fatals to errors which are executed only when you feed corrupted object files to the linker. As long as your object files are sane, such error handlers are unreachable.</div><div><br></div><div>If we really want to harden the linker to not crash for any input, that makes sense to recover from such errors (but this patch is far from enough as you might imagine). Or, instead, we can set a boundary between recoverable errors (as long as your object files are not broken, we guarantee that it will never segv/exit) and unrecoverable errors (your object files must be uncorrupted/your compiler must be trustworthy). In that sense, some part of my patches doesn't make much sense -- it was aiming the middle of the two which is not a sweet spot.</div><div><br></div><div>Hardening the linker would be a huge amount of work as Sean wrote, and it is not easy to imagine that that would worth it. It is also likely to greatly degrade runtime performance. Therefore, I think it is reasonable to choose the former policy -- caller must guarantee that the object files are not corrupted. What do you guys think?</div></div></div></div>