<div dir="auto">Maybe I'm missing something, but Why can't you just not generate a relocation that the JIT doesn't handle?</div><div><br><div class="gmail_quote"><div>On Mon, Sep 11, 2017 at 3:43 PM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Sep 11, 2017, at 3:37 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_4243748216501713765Apple-interchange-newline"><div><div><div class="gmail_quote"><div>On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I know there are two points of view here so I will give my two cents:<br>
<br>
If it comes down to something as easy as "always check for NULL before doing something", or something that is similar and very easy, I would say just code around it. Don't "assert(...)" or "llvm_unreachable(...)". Things that fall into this category: switch statements with defaults that might catch things, checking var/ivar for NULL, seeing if a collection is empty, bounds checking things.<br>
<br>
One example here is LLDB has its own object file readers for mach-o and ELF. Mach-o has load commands in the file header and each load command has a "cmd" uint32_t whose value is an enum. It is followed by a uint32_t "length" of this data. The LLVM version of the mach-o file parser, a while back before changes were made, wanted to assert or llvm_unreachable for any load command that it didn't recognize. This kind of thing can't happen in a debugger. </blockquote><div><br></div><div>Right, but that's user input.  On the other hand, suppose LLDB manually constructs some IR that it passes to the interpreter.  Since LLDB is in full control of the IR it generates, it can safely assert that the interpreter was successful at interpreting it.</div></div></div>
</div></blockquote></div><br></div><div style="word-wrap:break-word"><div>Like when you run an expression, it generated some relocation that the JIT doesn't handle and it crashes??? We ran into this a few times. So I don't agree that anything in the expression stack is not subject to these rules. It is something we should fix and we should not crash. So while unexpected things are harder to handle, I still say we should recover if at all possible and we ran into the relocations stuff not being handles many times over the years. We don't control user input that is in the expression.</div><div><br></div><div>If you are a shared library, you shouldn't crash if you can help it. If you are an executable, do what you want and feel free to crash yourself. We took LLDB out of process in Xcode so we could load unsigned code from Swift nightly builds, and another benefit was it didn't crash Xcode when things went wrong in LLDB. </div></div></blockquote></div></div>