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 <scalla...@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 <ztur...@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) > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
