<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Jim</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 8, 2017, at 7:18 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">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<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="gmail_quote"><div dir="auto" class="">On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank" class="">reviews@reviews.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
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.</blockquote><div dir="auto" class=""><br class=""></div></div></div><div class=""><div class="gmail_quote"><div dir="auto" class="">I don't agree that this is a settled issue in LLDB. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">For starters, clang already does this, and LLDB links against libclang.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">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</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>