aprantl added inline comments.
================ Comment at: lit/tools/lldb-mi/breakpoint/break-insert.test:14 +# CHECK-AFTER: ^running +# CHECK-AFTER: *stopped,reason="breakpoint-hit" + ---------------- labath wrote: > aprantl wrote: > > polyakov.alex wrote: > > > aprantl wrote: > > > > CHECK-AFTER is not recognized by FileCheck: > > > > > > > > https://www.llvm.org/docs/CommandGuide/FileCheck.html > > > > > > > > You probably saw this in a testcase that ran FileCheck twice, one time > > > > with the CHECK prefix and once with a custom > > > > `--check-prefix=CHECK-AFTER` which is a common trick to have more than > > > > one set of FileCheck directives in a single file. > > > Yes. There is no problem to write test using only `CHECK` and > > > `CHECK-NOT`, but as I said, in lldb-mi's output we can't find any info > > > about hitting breakpoint, so the question is: is it enough to check that > > > breakpoint was set to a selected target? > > > in lldb-mi's output we can't find any info about hitting breakpoint, > > Is that how the gdb/mi protocol is supposed to work or is that a bug or > > missing feature in lldb-mi? > > > > > so the question is: is it enough to check that breakpoint was set to a > > > selected target? > > If that's just how the protocol works then we'll have to make do with what > > we got. > That's not "how the protocol works" in general. It's how lldb-mi behaves when > it's control connection is closed. If you pipe its input from a file, lldb-mi > will get an EOF as soon as it processes the last command, interpret that as > the IDE closing the connection and exit (a perfectly reasonable behavior for > its intended use case). So it will never get around to printing the > breakpoint-hit message, because it will not wait long enough for that to > happen. If you make sure the stdin does not get an EOF then (either by typing > the same commands interactively, or by doing something like `cat > break_insert.test - | lldb-mi`, you will see the "hit" message does get > displayed (however, then the lldb-mi process will hang because it will expect > more commands). To make sure I understand your point: Does lldb-mi consumes input asynchronously from its command handler, so for example, when sending the mi equivalent of `b myFunc`, `r`, `p foo` — will lldb-mi wait until the breakpoint is hit or the target is terminated before consuming the next command after `r` or will it consume and attempt to execute `p foo` as soon as possible and thus potentially before the breakpoint is hit? If this is the case, we could introduce a "synchronized" mode for testing lldb-mi that behaves more like the SBAPI. Or we could pick up the idea you mentioned a while ago and produce a separate lldb-mi test driver that can send and get a reply for exactly one action at a time, similar to how the SBAPI behaves. Repository: rL LLVM https://reviews.llvm.org/D46588 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
