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

Rui Ueyama ruiu at google.com
Fri Aug 2 14:25:09 PDT 2013


I haven't though hard enough about that, but if I were a developer writing
IDE or something and wanted to use LLD, I would use it as a separate
process. It's not a matter of API usability but to protect the main program
from possible bugs of the library. It's like the latest browser spawns a
new process for each tab.


On Fri, 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.
>
> > -Nick
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130802/bf11b118/attachment.html>


More information about the llvm-commits mailing list