[Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Zachary Turner via lldb-commits]

I actually like the idea of feeding command lines. Again, not when the
command you're running prints a huge block of text and you try to match it.
But for "get the debugger into the state where i can reproduce the bug",
and sometimes the step to actually repro it, I think it's hands down the
best.

You can look at a test and tell in a few seconds how to repro it. You can
grok the test almost immediately. More importantly, it gives you everything
you need to repro it under a debugger. If you wanted to be fancy it could
even spit out a command file so you could get the test case failing in a
debugger in seconds


On Wed, Sep 14, 2016 at 6:02 PM Sean Callanan <scallanan at apple.com> wrote:

> I agree completely with tackling the easy stuff first.
> That said, the easy stuff (probably >50% of the testsuite) doesn't even
> require command-line interaction and is just of the form "stop here, run
> this one expression, maybe print this variable using 'frame variab'e'"
> I would argue that we can find a simpler way to handle these cases than
> feeding lldb command lines to the command-line parser.
> To be clear, that simpler way is not the SB API, it's probably a
> special-purpose language that knows how to stop at breakpoints and inspect
> locals/run expressions.  That's all it does.
> The SB API / command line parser argument is for what I'd argue are the
> complex cases, and I think we should deal with those later because they're
> both technically hairy and seem to attract more discussion.
>
> Sean
>
> On Sep 14, 2016, at 5:57 PM, Zachary Turner <zturner at google.com> wrote:
>
> 1. get all the easy stuff out of the way first, such as the tests in this
> patch (and there are probably at least 100 more that are just as easy)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160915/0fceb184/attachment.html>