[Lldb-commits] [PATCH] D37923: Implement interactive command interruption

[Jim Ingham via lldb-commits]

One of the fundamental goals of lldb is that it be an extensible debugger.  The extension mechanism for command line lldb all runs through the SB API through either Python or C++ (though most folks choose to use Python).  We know first hand that many people take advantage this mechanism to add custom commands specific to their workflows.  Again, look at the xnu macros for an example if you remain unconvinced of this.  Facebook also made a nice set of extension commands for introspecting UI elements when debugging iOS apps.  And every WWDC folks come with questions about how to implement some command or other.  If this doesn’t convince you also check out the effort the gdb folks have made and continue to make to support the Python extensions to what is purely a command-line debugger.

Not to mention that most of the powerful things you can do with breakpoint callbacks are available through the SB API's, and most sophisticated data formatters are written in Python.  And again based on questions and bug reports we get there are many people using this facility.

I’ve said this many times before, but the notion that the SB API’s are not a crucial part of the command-line lldb experience shows a fundamental misperception of the design of lldb.

Jim

> On Sep 20, 2017, at 7:37 AM, Zachary Turner <zturner at google.com> wrote:
> 
> 
> 
> On Tue, Sep 19, 2017 at 7:12 PM Jason Molenda <jmolenda at apple.com <mailto:jmolenda at apple.com>> wrote:
> 
> 
> > On Sep 19, 2017, at 6:57 PM, Zachary Turner via lldb-commits <lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>> wrote:
> >
> >
> >
> > After some additional thought, I stilled think testing below the sb api layer is more appropriate.
> >   While Xcode might be going through the SB api, users of upstream lldb (which is what we supposed to be testing upstream) are not.
> 
> 
> One thing to keep in mind is that while Xcode is the IDE using lldb that Apple directly supports, there are many other IDEs that are using lldb today.  I don't know for certain that all these are using SB API, but a partial list of additional IDEs in addition to Xcode includes CLion ("A Cross-Platform IDE for C and C+ by JetBrains"), Nuclide (atom based IDE), Android Studio, Visual Code Studio, and Eclipse (I know this one is done via lldb-mi).
> 
> Command line lldb is the interface I personally tend to prefer, but it is not the interface that the vast, vast majority of our users use when debugging with lldb.  SB API is.  The lldb driver is more akin to one front-end among many, and an odd one, given that it doesn't go through the SB API itself.
> 
> Definitely, but that's also one reason I think it's so important to split the tests up.  Right now there is almost no coverage of not going through the SB API, and yet that is the interface that we, as the upstream open-source project, provide to users.  And while it may not be the interface that the vast majority of users *currently* use, I think if we compared the number of people using GDB to the number of people using LLDB, it paints a different picture.  Namely, a picture of how many users *could* be using LLDB.  
> 
> I don't want to break any existing users of LLDB obviously, including those that go through the SB API, but at the same time the primary product that comes out of the open-source project is, in fact, a command line debugger, and we should strive to make that experience as good as possible.
> 
> I believe if the tests are split into private tests and public API tests you get the best of both worlds.  I would even go farther to say that the whole is greater than the sum of parts, because it makes it easy to write tests for any new api that comes along, and vastly reduces the barrier to entry to writing new tests, which I still believe is one of the most critical bugs facing the project today.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170920/ba7ce01a/attachment-0001.html>