<div>As LLVM is really a library it should behave like one and not just abort the whole process on an assert.</div>
<div> </div>
<div>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.</div>


<div> </div>
<div>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.</div>
<div> </div>
<div>Aaron<br><br></div>
<div class="gmail_quote">2009/8/20 Óscar Fuentes <span dir="ltr"><<a href="mailto:ofv@wanadoo.es">ofv@wanadoo.es</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> writes:<br><br>>>>> It's not about recovery, it's about message reporting.  Right now<br>>>>> the LLVM<br>

>>>> abort messages are formatted completely differently than aborts from<br>>>>> other<br>>>>> parts of our compiler.  That's not friendly to users.<br>>>><br>>>> This is what ErrorReporting.h is all about.<br>

>><br>>> But asserts and aborts don't go through that, right?  What's needed is<br>>> a way to get those assert and abort messages out to other compiler<br>>> components so they have a chance to report them nicely to the user.<br>

><br>> assert and abort should never happen, just like a null pointer or<br>> garbage pointer dereference should never happen.  How are garbage<br>> pointer and asserts different?<br><br></div>Well, an assert says the compiler is broken, but the compiler may be<br>

just another component of a large application. You are thinking on terms<br>of a traditional edit-run-crash compiler and on this scenario you are<br>right. No so for a JIT embedded on a server, where it plays a secondary<br>

role and it is not allowed to bring down the server because some random<br>piece of code uncovers a bug on the compiler or the LLVM backend.<br><br>--<br><font color="#888888">Óscar<br></font>
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>

<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></div></blockquote></div><br>