<div dir="ltr">FWIW, it can certainly use the SB API where it makes sense, but I think requiring that it only use the SB API would be very limiting and a big mistake.<div><br></div><div>The entire point of a tool such as this is that it allows you to dig deep into internals that would be difficult to access otherwise.  </div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 29, 2017 at 3:23 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Nov 29, 2017, at 2:51 PM, Zachary Turner via lldb-commits <<a href="mailto:lldb-commits@lists.llvm.org" target="_blank">lldb-commits@lists.llvm.org</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Nov 29, 2017 at 1:59 PM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> I'm mostly basing this concern on the bad effect this had on gdb all of whose testing was expect based command scraping.  gdb is a tool that's much closer to lldb than any of the compiler tools so that experience seems relevant.  It's been a decade or so since I worked on gdb, but back when I was working on it, you really had to tread very carefully if you wanted to change the output of, say, the break command, or to thread listings, etc, and a bunch of times I just had to bag some cleanup of output I wanted to do because fixing up all the tests was too time consuming.  Because Jason and I had both had this experience when we started working on lldb, we promised ourselves we wouldn't go down this path again...<br>
><br>
><br>
> Couple of things:<br>
><br>
> 1) I wouldn't dare to use this approach for anything that required interactivity.  If you need to run one command, extract a value from the output, and use that value as input to another command, I think that would be a big mistake.  I have no intention of ever proposing something like that.<br>
><br>
> 2) FileCheck is very flexible in the way it matches output and tests can be written so that they are resilient to minor format tweaks.  I have no doubt that with pure regex matching, or with pretty much any other tool, you would have a really bad time.  Of course, that doesn't mean it would be hard to construct an example of a format change that would break a FileCheck test.  But I think it would happen *far* less frequently than it did on GDB.  That said, I still understand your concerns that it's fragile, so...<br>
><br>
> 3) I would not be opposed to a tool called lldb-test, which was basically just LLDB with a different, and much more limited set of commands, and was completely non-interactive and would produce output in a format designed for being scraped, and which never had to be changed since it was never presented to the user.<br>
<br>
<br>
100% agree with #3.  We could go back and forth about using lldb-mi, but I think a specialized driver using SB API, designed for testing, would be a great approach.<br>
<br>
<br>
</blockquote></div>