Yes, the fact that llvm & clang and the MCJIT abort willy nilly has caused much pain to lldb. We don’t control that behavior and so are resigned to some continued suffering along those lines - though it seems like Lang is going to do a much cleaner job of handling problems in the new ORC JIT which will remove some significant source of that pain. And we have no intention of exacerbating it in areas we have more control over. That has been both Greg and my strong opinion since we started the work on lldb. Greg can weigh in on whether he has changed his mind about this, I have not.
BTW, the fact that lldb can run out of process doesn’t make it that much better. Because lldb caches the parse of object files from debugger to debugger it is much more efficient to keep one out of process lldb session running per targeted OS. So Xcode runs one for all the Native processes and one for each iOS device. But that means that you are still going to take down all the debug sessions for that target when the debugger goes down. So still quite undesirable. Jim > On Sep 8, 2017, at 7:18 PM, Zachary Turner <ztur...@google.com> wrote: > > Note that if something originates from user input, then i agree there's no > excuse for a fail fast. But after all the inputs have been sanitized, I think > it's fine to fast fail > On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner <ztur...@google.com > <mailto:ztur...@google.com>> wrote: > On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator > <revi...@reviews.llvm.org <mailto:revi...@reviews.llvm.org>> wrote: > > I know there is debate about this one side and another but for lldb this is a > settled issue. Unless you really are in a state where the world is about to > come crashing down around you, you can't raise a fatal error in lldb. And in > this case, the world is only very minorly strange, so it is certainly not > appropriate. > > I don't agree that this is a settled issue in LLDB. > > For starters, clang already does this, and LLDB links against libclang. > > Second, a year or so ago, i recall Greg saying that LLDB now runs out of > process in Xcode, which should make this a non issue. > > Finally, by allowing inconsistent state to propagate through the code you are > only hurting yourself, as you're ultimately not preventing any crashes. > It'll just crash later when you de reference a null pointer or read some > corrupt memory. Furthermore, it actually increases the likelihood of > introducing bugs, due to the added complexity and technical debt introduced > by untested code paths
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits