llvm dev - Oct 2008 - [LLVMdev] 2.4 Pre-release (v1) Available for Testing

On Sat, Oct 11, 2008 at 1:24 PM, Kenneth Boyd <zaimoni at zaimoni.com>
wrote:
> /* snip */
Actually, my biggest issue with llvm (which highly impacts testing as
well) is the use of abort(), which I have resolved in my local copy by
just searching for the full word "abort" everywhere and just replacing
them with exceptions that relay what happened.  Reason this is my
biggest issue is that the llvm library is just a part of the full
program that will be using it, and I cannot have llvm abort()ing on
some bad passed in code when this application needs to have the best
possible up-time, I need to send a message back to the node saying
that the compile failed, not crash.  I can understand using abort in
little one-off programs like llc or opt or something that just does
one function and ends, but llvm is a library, as such it may be in
programs that need to stay persistently up, the use of abort()
everywhere is really painful in such circumstances, even an error
handler that can be registered by the parent app into the library
would work better, although I prefer exceptions for these since they
truly are exceptional events.  Personally I also do not like asserts
either, as that is indicating you are expecting something bad to
happen; such a circumstance should have code to handle it, or throw an
exception.

Which makes me curious, if I submitted a patch that got rid of llvms
use of abort()s all over the place, and replaces them with exceptions
(the program dies either way if it is unhandled, but with exceptions
you at least get a chance to handle it and recover), what is the
chance it would be accepted, especially since I see no usage of
exceptions at all (even if it passes through the C api, think about
it, if an abort occurs, the program dies, if an exception is thrown
through the C api, the program still dies, either way it dies,
where-as when using the C++ interface you can at least handle it so
the parent application need not die).  Could always go with
registering an error handler with the llvm api, but that would require
more code...

OvermindDL1 wrote:
> On Sat, Oct 11, 2008 at 1:24 PM, Kenneth Boyd <zaimoni at
zaimoni.com> wrote:
>   
>> /* snip */
>>     
>
> Actually, my biggest issue with llvm (which highly impacts testing as
> well) is the use of abort(), which I have resolved in my local copy by
> just searching for the full word "abort" everywhere and just
replacing
> them with exceptions that relay what happened.  ....  Personally I also do
not like asserts
> either, as that is indicating you are expecting something bad to
> happen; such a circumstance should have code to handle it, or throw an
> exception.
>   
Well, use release mode to get rid of all of the asserts ;)

The abort() usages are slightly annoying, but (long-term) I would handle 
those by forking LLVM and wrapping them in #ifndef NDEBUG
.
> Which makes me curious, if I submitted a patch that got rid of llvms
> use of abort()s all over the place, and replaces them with exceptions
> (the program dies either way if it is unhandled, but with exceptions
> you at least get a chance to handle it and recover), what is the
> chance it would be accepted, especially since I see no usage of
> exceptions at all
I do not have seniority to directly answer this question.  That said, 
this has been proposed within the past three months -- and rejected.  I 
don't recall the exact rationale off-hand.

Kenneth

Please use subjects that have something to do with the content, this  
discussion has nothing to do with 2.4

On Oct 11, 2008, at 1:01 PM, OvermindDL1 wrote:
> On Sat, Oct 11, 2008 at 1:24 PM, Kenneth Boyd <zaimoni at
zaimoni.com>
> wrote:
>> /* snip */
>
> Actually, my biggest issue with llvm (which highly impacts testing as
> well) is the use of abort()...
>  I cannot have llvm abort()ing on
> some bad passed in code
There are better solutions to that: 1) ensure you don't ever pass the  
llvm backend invalid code, and 2) use the llvm IR verifier to reject  
code before sending it to the backend.
> Which makes me curious, if I submitted a patch that got rid of llvms
> use of abort()s all over the place, and replaces them with exceptions
> what is the
> chance it would be accepted,
There is no chance, we worked hard to eliminate exceptions and are  
aiming to eliminate the last couple remnants of RTTI.  Sending invalid  
code into the backend is violating a very important invariant in the  
API.  I don't see how it would be any different then passing in a null  
pointer or garbage pointer into an API that would then bus error.

-Chris

Hi,
> Which makes me curious, if I submitted a patch that got rid of llvms
> use of abort()s all over the place, and replaces them with exceptions
> (the program dies either way if it is unhandled, but with exceptions
> you at least get a chance to handle it and recover),
since LLVM may well be left in an inconsistent state internally if
an exception is thrown, it wouldn't be safe to continue using it
after catching an exception.

Ciao,

Duncan.

On Sun, Oct 12, 2008 at 1:16 AM, Duncan Sands <baldrick at free.fr>
wrote:
> Hi,
>
>> Which makes me curious, if I submitted a patch that got rid of llvms
>> use of abort()s all over the place, and replaces them with exceptions
>> (the program dies either way if it is unhandled, but with exceptions
>> you at least get a chance to handle it and recover),
>
> since LLVM may well be left in an inconsistent state internally if
> an exception is thrown, it wouldn't be safe to continue using it
> after catching an exception.
The unwinding should clean things up, and it can be enforced in such a
way so that, for example, the module is destroyed if such a thing
happens.  Useful in my case because either a script compiles, or it
fails and dies (thus returning a message back to the caller saying it
failed, all state information I needed to keep around can be nicely
dumped).  Exceptions are not the only method though, there are others,
but regardless it still needs to not just 'die'...

You're right that LLVM may be left in an unusable state --- I've  
encountered that problem on my own.

However, even a simple exit function would be useful.  If, instead of  
calling abort, LLVM called a function pointer I provided life would be  
much easier.  Even if the function call simply threw up a crash screen  
life would be better than calling abort. Ideally I'd like to throw an  
exception, and terminate gracefully.

Robert

> Hi,
>
>> Which makes me curious, if I submitted a patch that got rid of llvms
>> use of abort()s all over the place, and replaces them with exceptions
>> (the program dies either way if it is unhandled, but with exceptions
>> you at least get a chance to handle it and recover),
>
> since LLVM may well be left in an inconsistent state internally if
> an exception is thrown, it wouldn't be safe to continue using it
> after catching an exception.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Saturday 11 October 2008 23:13:46 Chris Lattner
wrote:
> On Oct 11, 2008, at 1:01 PM, OvermindDL1 wrote:
> > Which makes me curious, if I submitted a patch that got rid of llvms
> > use of abort()s all over the place, and replaces them with exceptions
> > what is the chance it would be accepted,
>
> There is no chance, we worked hard to eliminate exceptions and are
> aiming to eliminate the last couple remnants of RTTI.  Sending invalid
> code into the backend is violating a very important invariant in the
> API.  I don't see how it would be any different then passing in a null
> pointer or garbage pointer into an API that would then bus error.
One difference is that programs written in safe languages that call LLVM 
should never be able to pass null or garbage pointers to LLVM but they can 
pass invalid data structures or make invalid sequences of calls and it is 
perfectly feasible to handle the errors gracefully if this happens.

The main issue for me is that any bug in my use of LLVM during development 
causes it to die in such a way that I cannot get a stacktrace to find out 
where the error occurred in my OCaml code.
>From your description, I assume the solution is to use signal handlers to 
catch the "abort()" from LLVM in LLVM's OCaml bindings and raise
an exception
on the OCaml side.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e