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: > 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. > 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? I know very little about lldb-mi implementation or the gdb-mi protocol, but yes, that is what I think is happening. In general, you need the ability to issue asynchronous commands, if for nothing else, then to implement the equivalent of ^C. gdb-remote protocol also multiplexes reading from the socket and waiting on inferior state change for this reason (and would respond the same way if you tried to feed it input from a file). BTW: SB API also has an asynchronous mode, and I think it is even the default. It's just that we switch it to synchronous mode for testing, as one does not care about the ability to interrupt the process in tests (most of the time). > 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. I think both of these are valid options. Probably the simplest way to implement the first one would be to introduce a `-wait-for-target-to-stop` command (maybe there is one already ??). The advantage of the second one is that we will have the ability to inject commands which depend on the results of previous commands (something that I think we will need, sooner or later). 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
