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 allI 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 codeThere 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 tocatch 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
Reasonably Related Threads
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing