Now, at least in release 3.7.1, on an encounter with a fatal error at the time of compiling a module it will call an installed handler function and allow the application to log the error etc. However once said handler returns LLVM will force an exit of 0x1, something that I cant allow to ever occur, but according to the ErrorHandling header I cant safely throw an exception to back out of the error either?
So what would be the most ideal way of recovering the application from such an event?
I’d be pretty sure the definition of a fatal error is one that can’t be continued from - though I’m not familiiar with this particular LLVM hook/details.
I should be able to flush/shutdown everything and reinit/restart it like I
do everything else, it would be pretty bad design to not be able to.
Yeah, it's far from perfect, but error handling can be difficult/expensive
to weave through every layer. So for certain kinds of errors we don't do
that sort of thing.
On a similar issue, calling llvm_shutdown and reinitialising everything
leads to problems as it doesn't appear that llvm is being reinitialised
correctly, this seems to be a bug unless there's an extra function call I'm
missing that isn't needed at first startup?
In theory this should work, of course - if you've got specific things that
seem to not be working, might be worth filing a bug, etc?
I'm not sure how well tested/exercised the llvm_shutdown path is. (equally,
most stuff should just be in the LLVMContext & should be able to destroy
that and make a new one without the full shutdown/re-init, not sure if that
path is any better tested/used, though)
(perhaps someone else on llvm-dev can chime in if I'm giving an incorrectly
pessimistic representation of the state of things)
Recovering from fatal errors by throwing an exception might work, and
you're welcome to try it. I've heard that people do this and it "works" in
practice. Just be aware that we don't provide a warranty. We're especially
bad at reinitializing.