llvm dev - Aug 2009 - [LLVMdev] LLVM asserts

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

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>

On Wed, Aug 19, 2009 at 5:27 PM, Aaron
Gray<aaronngray.lists at googlemail.com> wrote:
> As LLVM is really a library it should behave like one and not just abort
the
> whole process on an assert.
This isn't Java; if we hit an assert, it's likely memory is in an
inconsistent state, so we don't want to try to recover.

-Eli