[llvm-dev] [RFC] Error handling in LLVM libraries.
Lang Hames via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 3 15:52:34 PST 2016
> "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".
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
> 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>
>> 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.)
>> 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...
More information about the llvm-dev