[llvm-dev] lld: ELF/COFF main() interface

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 26 09:34:34 PST 2016


I'd think it is probably better to discontinue this thread. I have a local
patch to do what I can at this moment. I'll send it for review, so let's
discuss on that review thread.

On Tue, Jan 26, 2016 at 9:25 AM, Rafael EspĂ­ndola <llvm-dev at lists.llvm.org>
wrote:

> > I believe, however, that even when we want this functionality in a
> library, we don't want the implementation to be "error_code spaghetti."
>
> My opinion too. If some utility code is really useful, sure, we add
> error_code and move it to llvm, but I would like to avoid having all
> of lld look like that.
>
> > I propose that, for the purpose of treating lld as a library, we enable
> exception handling and use C++ exceptions. All of my users who use LLVM
> components as a library (for JIT, etc.) insist that I build LLVM with
> exceptions (and RTTI for that matter) enabled. For the purpose of creating
> a stand-alone lld build, we could certainly build with exceptions disabled
> if that yields a measurable performance difference.
> >
> > Thoughts?
>
> Something along those lines should work. We would probably still need
> a diag handler, but it would now *not* be fatal and 'error' would look
> like
>
> * call diag handler
> * if no exceptions, exit(1)
> * else, throw
>
> The reason being that it is a lot easier to print errors close to
> where they are found and we want to do it when exceptions are disabled
> too.
>
> Thanks,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/0beeaff6/attachment.html>


More information about the llvm-dev mailing list