[lldb-dev] LLDB Evolution - Final Form

[Enrico Granata via lldb-dev]

> On Sep 19, 2016, at 2:31 PM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 
> 
> On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
> 
> 
> I’m surprise by your aversion to assertions, what is your suggested alternative? Are you expecting to check and handle every possible invariants everywhere and recover (or signal an error) properly? That does not seem practical, and it seems to me that it'd lead to just involving UB (or breaking design invariant) without actually noticing it.
> 
> > Also many asserts are in header files so even if you build llvm and clang with asserts off, but then build our project that uses LLVM with asserts on, you get LLVM and clang asserts when you don't want them.
> 
> It is not really supported to use the LLVM C++ headers without assertions and link to a LLVM build with assertions (and vice-versa).
>  
> It seems to me that you are mixing two things: asserting on user inputs vs asserting on internal invariants of the system. LLVM is very intensive about asserting on the second category and this seems fine to me.
> Asserting on external inputs is not great (in LLVM as much as in LLDB).
> 
> The asserting error class above falls into the second category and is a great tool to enforce programmer error
> 
> 
> I can kind of see both sides on this one.  Yes, if you can catch instances of UB before it happens that's helpful.  At the same time, when you've got a product (such as, say, Xcode), you also want to try as hard as possible not to bring the whole product down.  In lldb we have lldbassert, which asserts for real in debug, but in release it logs an error to a file.  This is nice because if someone submits a crash report, we can see the assertion failure in the log file.
> 
> Now, obviously the *real* solution is to make LLDB out-of-process so it doesn't bring down Xcode when it crashes.  But (and I have no knowledge of the Xcode / LLDB integration) I can easily see this being a monumental amount of effort.
> 

Even then, IMO you are not out of the business of not crashing on people
Sure, now you didn't crash all of Xcode, but you still lost somebody's debug session with potentially valuable state in it...

It sounds like llvm::Expected + lldbassert() is a good combination; it makes sure we don't just drop error conditions on the ground, but it also makes sure that we don't just give up the ghost and crash..

> Personally, asserting in LLDB doesn't affect me and I'm fine with lldb::Error asserting..  But I can kind of see the argument for not wanting it to assert.  
> 
> On the other hand, if we had better test coverage, then all

I wonder if catching them all can't somehow be reduced to the halting problem :) Most would already be great!

> of these assertions would be caught during test anyway.  Which brings us back to item #2 on my list...
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160919/ac6e3eec/attachment.html>