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? - Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/8c4f67d7/attachment.html>
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. On Wed, Mar 9, 2016 at 2:57 PM, Paul Hancock via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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? > > - Paul > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/a8f765b6/attachment.html>
On Wed, Mar 9, 2016 at 7:42 PM, Paul Hancock <Paul.Hancock.17041993 at live.com> wrote:> 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)> > - Paul > > > > > > ------------------------------ > *From:* David Blaikie <dblaikie at gmail.com> > *Sent:* 10 March 2016 10:23 > *To:* Paul Hancock > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] LLVM Fatal Error Handling > > 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. > > On Wed, Mar 9, 2016 at 2:57 PM, Paul Hancock via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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? >> >> - Paul >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/c289fc29/attachment.html>
On Wed, Mar 9, 2016 at 9:42 PM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Wed, Mar 9, 2016 at 7:42 PM, Paul Hancock < > Paul.Hancock.17041993 at live.com> wrote: > >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160310/a82f2f0c/attachment-0001.html>