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

[Adrian Prantl via Phabricator via llvm-commits]

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