If you really want to replicate the steps manually: (lldb) script >>> type Python commands here using the LLDB API
There might be a little bit of translation involved, for instance in your test you might say self.frame().FindVariable(“foo”) which would not work at the interactive interpreter - and would become lldb.frame.FindVariable(“foo”) A better solution is the “-d” flag to dotest.py that puts the test suite driver in a STOPPED state until someone attaches to the matching Python process - then you can set breakpoints as you usually would in places you care about, and debug > On Mar 18, 2015, at 4:49 PM, Chaoren Lin <chaor...@google.com> wrote: > > Whenever I debug a test with runCmd/expect, I could just grep for runCmd in > the test trace and execute the same steps manually (or just paste everything > in). It's especially useful if I need another debugger attached to lldb. > AFAICT, with the SB API, I'd need to look at the test script and translate > everything myself. Is there a way to do this automatically, or is there a > better workflow that I don't know of? > > On Wed, Mar 18, 2015 at 4:19 PM, <jing...@apple.com > <mailto:jing...@apple.com>> wrote: > I don't mean to pick on Chaoren here, his latest patch just reminded me of > this, so I thought I'd repeat it... > > We strongly prefer writing test cases using the SB API's rather than the > runCmd & expect. Unless you are actually testing some feature of the command > line, please don't write command based tests. I realize that there are > plenty of examples of tests in the test suite that use runCmd where they > shouldn't, but don't copy them, copy the plenty that do use the SB API's > instead. > > The reason for this is that our policy is that we will maintain compatibility > with the SB API's - at least till we decide to do an API-2.0. But we don't > make any similar guarantee about the details of command result format. If > your test is using the command line, it is going to have to check against the > command result, and you either end up writing your check pattern by checking > as little as possible so you won't be exposed to random changes, in which > case you can end up missing some failure, or you test too much and it means > irrelevant changes break your tests. > > If you use the Python API's it is possible to check all the results you want > to check in a very explicit way, which makes the tests much more robust. > > Even if you are testing that a command-line command does some specific thing, > it is still better in general to use the SB API's to drive to the point where > you want to run the test, then use SBInterpreter::HandleCommand to run the > command. You get the full result text from the command in the command return > object, and all the part where you are driving the debugger to the point you > want to test will be more robust. > > BTW, I don't think we've said this anywhere, I just added a note to this > effect to the Testsuite README. > > Jim > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > <http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev> > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
