[PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.

[Pavel Labath via Phabricator via llvm-commits]

labath added inline comments.


================
Comment at: lit/tools/lldb-mi/breakpoint/break-insert.test:14
+# CHECK-AFTER: ^running
+# CHECK-AFTER: *stopped,reason="breakpoint-hit"
+
----------------
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).


Repository:
  rL LLVM

https://reviews.llvm.org/D46588