[llvm-dev] [RFC] Error handling in LLVM libraries.

[Lang Hames via llvm-dev]

Hi Philip,

> Separate from the discussion on how we represent errors, we need to
decide what errors we want to detect, which we try to diagnose, and which
are recoverable.  Each of these is a distinct design decision.

Absolutely. This proposal should be interpreted with that in mind - it
gives us a better toolkit for describing certain kinds of errors, but it
should not be shoehorned into situations where it does not fit.
Programmatic errors are an obvious example: they should remain hard errors
(asserts/report_fatal_error/llvm_unreachable).

On MCJIT/Orc - I'm glad the current situation hasn't caused you too much
pain, but other clients have complained about it. I think the key
observation is that neither MCJIT nor ORC assume that the bit code they're
compiling is in-memory. That means that both should be able to report
"resource not available" errors (e.g. when JITing bitcode off a network
mount that has temporarily dropped out). This problem has become especially
acute now that we have library support for remote-JITing: Any call to any
lazily compiled function may fail due to resource drop-outs, and we should
be able to report that to the user to give them a chance to try to recover
and re-try compilation.

On the commitment front: The driving use case for me currently is the llvm
object-file tools and LLD, but I know that proper error handling in the JIT
is something I want to tackle in not-too-distant future, so having a
toolkit to deal with it is a big step in the right direction.

- Lang.



On Wed, Feb 3, 2016 at 3:02 PM, Philip Reames <listmail at philipreames.com>
wrote:

>
>
> On 02/02/2016 05:29 PM, Lang Hames via llvm-dev wrote:
>
> Hi All,
>
> I've been thinking lately about how to improve LLVM's error model and
> error reporting. A lack of good error reporting in Orc and MCJIT has forced
> me to spend a lot of time investigating hard-to-debug errors that could
> easily have been identified if we provided richer error information to the
> client, rather than just aborting. Kevin Enderby has made similar
> observations about the state of libObject and the difficulty of producing
> good error messages for damaged object files. I expect to encounter more
> issues like this as I continue work on the MachO side of LLD. I see
> tackling the error modeling problem as a first step towards improving error
> handling in general: if we make it easy to model errors, it may pave the
> way for better error handling in many parts of our libraries.
>
> Separate from the discussion on how we represent errors, we need to decide
> what errors we want to detect, which we try to diagnose, and which are
> recoverable.  Each of these is a distinct design decision.
>
> For instance, I'd be really curious to hear more about your use case in
> Orc and MCJIT.  We're using MCJIT and I've found the error model presented
> to be perfectly adequate for our purposes.   I've sometimes wished that
> MCJIT did a slightly better job *diagnosing* failures, but I have yet to
> see a case where I'd actually want the compiler to recover from incorrect
> input rather than failing with a clean message so that I can fix the bug in
> the calling code.
>
> One thing I'm seriously concerned about is setting false expectations.
> Unless we are actually going to invest in supporting recovery from (say)
> malformed input, we should not present an interface which seems to allow
> that possibility.  A hard failure is *much* preferable to a soft error with
> the library in a potentially corrupt state.  I have seen several software
> projects head down the road of soft errors with partial recovery and it's
> *always* a disaster.  (Your proposal around checked-by-default errors is a
> good step in this direction, but is not by itself enough.)
>
> Philip
>
> p.s. I'm purposely not commenting on the representation question because I
> haven't read the proposal in enough detail to have a strong opinion.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160203/83886869/attachment.html>