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

[Rui Ueyama via llvm-commits]

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