[PATCH] D16668: ELF: Remove fatal() and add the second parameter to the linker's entry point.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 2 08:39:19 PST 2016

On Mon, Feb 1, 2016 at 10:36 PM, Sean Silva via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Mon, Feb 1, 2016 at 11:43 AM, Rui Ueyama <ruiu at google.com> wrote:
>> On Mon, Feb 1, 2016 at 11:18 AM, Sean Silva <chisophugis at gmail.com>
>> wrote:
>>> silvas added a subscriber: silvas.
>>> silvas added a comment.
>>> In http://reviews.llvm.org/D16668#340546, @rafael wrote:
>>> > I don't think so.
>>> >
>>> > 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.
>>> >
>>> > If we cannot produce a segmentation fault, we will need another way of
>>> fixing this.
>>> 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.
>>> 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.
>> 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.
>> 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.
>> 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?
> You mean basically:
> - for valid object files: it is a bug in LLD if the linker crashes or
> otherwise does not return to its caller
> - for corrupted object files: error recovery is not guaranteed. We may use
> fatal error handling for convenience or may even segfault.
> ?

(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))


> I think that is a sweet spot, and pretty much what LLD currently does
> (after your recent patches land).
> 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).
> -- Sean Silva
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160202/970347cd/attachment.html>

More information about the llvm-commits mailing list