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

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added a comment.

In https://reviews.llvm.org/D46588#1099566, @clayborg wrote:

> In https://reviews.llvm.org/D46588#1099536, @aprantl wrote:
>
> > > 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...
> >
> > If one doesn't exist then I think it would be reasonable to invent one. Handling an additional command that is used in testing only should not break any existing clients.
>
>
> I am not sure I like the direction of "lets test lldb-mi in a way that doesn't behave like a real debug session" by making new testing stuff so we can text scrape.


There are two levels that we want to test lldb-mi on:

1. Test on the functionality / specification level: We want to make sure that a specific lldb-mi command triggers a specific action. To test this as reliably as possible getting rid of any temporal uncertainty is a good thing. This is what I'm concerned with here. The idea is to serialize an entire debug session with fixed inputs into one output file, which can then be checked via FileCheck. You are right that this is "scraping text", but I do think that that is the appropriate abstraction level for testing a textual protocol. The main befit of doing it this way is that there is no pexpect and timeouts involved (other than the per-test timeout imposed by the lit driver). This way we get a very reliable testsuite that is not affected by how much load the machine running it is under.

2. Test end-to-end that lldb-mi integrates well with an interactive client. I don't actually have any good ideas for how to do this beyond the existing pexpect-based method, which, as we found out, has some reliability issues. But perhaps reducing the number of interactive tests in favor of mostly specification (1) tests will reduce the chances of a random timeout occurring to a manageable number.


Repository:
  rL LLVM

https://reviews.llvm.org/D46588