[lld] r187670 - Use report_fatal_error() instead of llvm_unreachable() to show broken input file error.

[Nick Kledzik]

On Aug 2, 2013, at 2:13 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> This really should return an error_code.  When lld is a library inside an app like an IDE, we don’t want to kill the whole app because of a malformed object file.
> 
> No opinion about this particular error, but do we really want to use
> lld like that? As far as I can tell clang is not used like that. IDEs
> (and all build systems really) just for exec clang. Given that there
> are a lot more compile jobs than link jobs (and the clang driver forks
> to run clang -cc1), it is not clear that the savings for not doing a
> fork+exec for the linker would be noticeable.
> 
> Second, http://llvm.org/docs/CodingStandards.html#assert-liberally has
> been in effect since forever, so even if all of lld and lib/Object are
> "perfect", the IDE would still have to fork+exec when doing LTO, since
> it seems almost impossible to change all of the middle end passes and
> code generators to avoid assert, llvm_unreachable and
> report_fatal_error.

I don’t know if a client ever will embed the linker like that, but we designed the APIs to return error_code so that it could be possible to do that.  So, in this case it was odd to not return an error code.  

I have similar issues with the darwin linker.  In lots of places I have asserts which are really checking object file content issues.  Users of the linker freak out when a malformed object file causes the linker to crash/assert.  It would be much better if the parsing code returned an error up the call chain so that the driver could  print out the path to the malformed object file.

-Nick