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

[Lang Hames via llvm-dev]

Oops...

> "I think the key observation is that neither MCJIT nor ORC assume that
the bit code they're compiling is in-memory."

IR is obviously always in memory. This should be "neither MCJIT nor ORC can
assume that the objects being linked are in-memory".

- Lang.

On Wed, Feb 3, 2016 at 3:19 PM, Lang Hames <lhames at gmail.com> wrote:

> 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/abd83b68/attachment.html>