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

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 1 22:36:11 PST 2016

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160201/0173066c/attachment.html>

More information about the llvm-commits mailing list