<div dir="ltr">Oops... <div><br></div><div>> "<span style="font-size:13px">I think the key observation is that neither MCJIT nor ORC assume that the bit code they're compiling is in-memory.</span><span style="font-size:13px">"</span></div><div><span style="font-size:13px"><br></span></div><div>IR is obviously always in memory. This should be "neither MCJIT nor ORC can assume that the objects being linked are in-memory".</div><div><br></div><div>- Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 3:19 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Philip,<span class=""><div><br></div><div>> <span style="font-size:13px">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.</span></div><br style="font-size:13px"></span><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Lang.</div><div><br></div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 3:02 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<br>
<br>
<div>On 02/02/2016 05:29 PM, Lang Hames via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span style="font-size:13px">Hi All,</span>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">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.</div>
<div style="font-size:13px"><br>
</div>
</div>
</blockquote></span>
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.<br>
<br>
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. <br>
<br>
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.)<span><font color="#888888"><br>
<br>
Philip<br>
</font></span><br>
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. <br>
<br>
<br>
<br>
</div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>