Maybe I'm missing something, but Why can't you just not generate a relocation that the JIT doesn't handle?
On Mon, Sep 11, 2017 at 3:43 PM Greg Clayton <clayb...@gmail.com> wrote: > > On Sep 11, 2017, at 3:37 PM, Zachary Turner <ztur...@google.com> wrote: > > On Mon, Sep 11, 2017 at 3:31 PM Greg Clayton via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > >> I know there are two points of view here so I will give my two cents: >> >> 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. >> >> 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. > > > 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. > > > 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. > > 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. >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
