[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue May 15 05:42:52 PDT 2018
labath added inline comments.
Comment at: lit/tools/lldb-mi/breakpoint/break-insert.test:10
+# CHECK-AFTER: ^done
> labath wrote:
> > polyakov.alex wrote:
> > > labath wrote:
> > > > I'm not familiar with this directive. Are you sure that this actually does anything?
> > > I tried to use only CHECK directive, but got errors like pattern not found, so I decided that it may be caused due to CHECK search features, for example, as I know, it finds pattern from the start of the file. If we want to check lldb-mi output, we should follow a specific order.
> > >
> > > In our case, we should find "^done" string directly after -break-insert command's output.
> > I think you got the FileCheck operation wrong.
> > a `CHECK` should always start matching from the previous match. The reason that this is passing for you now is that CHECK-AFTER is a non-existing directive and FileCheck ignores it (try replacing it with a bogus string and see if it still passes). if `CHECK` is not working for you here then you probably have the pattern wrong.
> You are right about the CHECK-AFTER. I wrote the test using only check and found an issue:
> after executing of -exec-run command, we expect to see output like:
> but, I think, that FileCheck check file for the pattern, while a -exec-run hasn't finished yet. It means that there will not be expected output and we'll get the error: no such pattern.
> Is there a mechanism to add some delay to FileCheck to wait until -exec-run finished?
There shouldn't be a need for anything like that. FileCheck will wait until EOF before doing anything. In fact, if you try running the test script manually (`lldb-mi <break-insert.test`), you will see that lldb-mi in fact does *not* print out the `*stopped` line. What I expect is happening here is that lldb-mi reaches EOF, and then decides there is nothing left for it to do and exits (a somewhat reasonable assumption given that it's expecting to be talking via an interactive link).
This sounds like a fairly fundamental problem with the lit+FileCheck testing strategy. If we're not able to come up with a command to make lldb-mi wait until the target stops (maybe there is one already? I know very little about lldb-mi), we may have to revisit the whole testing strategy...
More information about the lldb-commits