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

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'...

> >> 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,
yes, but it currently doesn't always.  It takes careful design to get a
system that chugs on merrily in spite of exceptions.  LLVM wasn't designed
that way.  You can of course add code to make it robust - be my guest.
> 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'...
If you just want to print some messages and then die, that would work.
There are probably many ways of getting this effect besides using
exceptions (I guess this is what you are saying in the last paragraph).

Ciao,

Duncan.

On Oct 12, 2008, at 7:26 AM, Duncan Sands 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
>>>> (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,
>
> yes, but it currently doesn't always.  It takes careful design to  
> get a
> system that chugs on merrily in spite of exceptions.  LLVM wasn't  
> designed
> that way.  You can of course add code to make it robust - be my guest.
Again, while anyone is welcome to do this, it won't be accepted back  
into the main repository. There are better ways of accomplishing this  
than exceptions.  Exceptions have a huge cost on the whole system and  
LLVM has to serve multiple clients well.

-Chris