<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 10:36 PM, Sean Silva via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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"><div><div class="h5">On Mon, Feb 1, 2016 at 11:43 AM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.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"><div class="gmail_extra"><div class="gmail_quote"><span>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></span><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></blockquote><div><br></div></div></div><div>You mean basically:</div><div>- for valid object files: it is a bug in LLD if the linker crashes or otherwise does not return to its caller</div><div>- for corrupted object files: error recovery is not guaranteed. We may use fatal error handling for convenience or may even segfault.</div><div>?</div></div></div></div></blockquote><div><br></div><div>(FWIW, I think that's still going to be a transient point - we'll eventually want an actual API that doesn't crash. The equivalent to LLVM here is that in-memory files may be trusted (in the same way that in-memory IR can be trusted/assumed to be verifier clean) but API users may still want/need to call into lld and not crash on uncontrolled inputs (files off disk) - in the "integrate with the clang driver" example, the clang driver may be driving the linker on unknown object files the user provided & a hard stop/exit within the API may still be problematic (perhaps some object files were provided and some source files - source files are compiled into object files, then the linker is run - linker hard stops on one of the user provided object files (or one of the generated object files is corrupted between write and read) and the compiler still needs to cleanup its temporary object files))</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></div></div></div></blockquote><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><br></div><div>I think that is a sweet spot, and pretty much what LLD currently does (after your recent patches land).</div><div><br></div><div>Whatever we ultimately decide, it is probably worth writing it down somewhere, if only to have an official reference in future discussions (it will help focus future discussions I think because we will have a concrete point of reference).</div><div><br></div><div>-- Sean Silva</div><div><br></div><div><br></div><div><br></div></div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>