[LLVMdev] LLVM asserts

Aaron Gray aaronngray.lists at googlemail.com
Wed Aug 19 17:27:46 PDT 2009


As LLVM is really a library it should behave like one and not just abort the
whole process on an assert.

Ideally we should be able to implement so set of options where an assert can
cause one of a number of error mechanisms to be used from SIGABT to throwing
and execption object containing line number file and the error message. This
would require replacing asserts with say an llvm_assert( bool, char*) style
preprocessor call that can generate the desired response, throw an error to
be catched by a handler or doing a C++ throw, depending on how it is
defined.

I was intending to look into this after implementing the COFF Writer. It
should not be too much work to convert the asserts into an llvm_assert, iirc
there are about 500 of them.

Aaron

2009/8/20 Óscar Fuentes <ofv at wanadoo.es>

> Chris Lattner <clattner at apple.com> writes:
>
> >>>> It's not about recovery, it's about message reporting.  Right now
> >>>> the LLVM
> >>>> abort messages are formatted completely differently than aborts from
> >>>> other
> >>>> parts of our compiler.  That's not friendly to users.
> >>>
> >>> This is what ErrorReporting.h is all about.
> >>
> >> But asserts and aborts don't go through that, right?  What's needed is
> >> a way to get those assert and abort messages out to other compiler
> >> components so they have a chance to report them nicely to the user.
> >
> > assert and abort should never happen, just like a null pointer or
> > garbage pointer dereference should never happen.  How are garbage
> > pointer and asserts different?
>
> Well, an assert says the compiler is broken, but the compiler may be
> just another component of a large application. You are thinking on terms
> of a traditional edit-run-crash compiler and on this scenario you are
> right. No so for a JIT embedded on a server, where it plays a secondary
> role and it is not allowed to bring down the server because some random
> piece of code uncovers a bug on the compiler or the LLVM backend.
>
> --
> Óscar
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090820/3b26d083/attachment.html>


More information about the llvm-dev mailing list