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

Reply via email to