[Lldb-commits] [PATCH] D53731: [NativePDB] Add the ability to display global variables

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D53731#1276743, @vsk wrote:

> In https://reviews.llvm.org/D53731#1276732, @zturner wrote:
>
> > In https://reviews.llvm.org/D53731#1276660, @jingham wrote:
> >
> > > Could you also use Vedant's new FileCheck dotest test class?  That should allow you to write the tests exactly as you are, but use the dotest mechanism to build and run the example.
> >
> >
> > Adding Vedant here.  My understanding is that the work he did there is like the inverse of what I'm doing.  It allows you to use FileCheck from inside of dotest tests, but I was trying to bypass dotest here.  I don't necessarily think "dotest for all things" should be an explicit goal (i actually think long term we should move away from it, but that's for another day).  Aside from that though, I don't think this particular test needs any of the functionality that dotest offers.  It offers building in multiple configurations, but we can get that from this test by just specifying mulitple run lines (I'm testing this out locally and it seems like I can get it to work).  Eventually, using some kind of configuration / builder type system like I brainstormed in the review thread I linked previously, I think we could have all the advantages of dotest's builder even with this style of test.
> >
> > FWIW, I was also under the impression that Vedant's solution with FileCheck in dotest was only intended as sort of an immediate solution to a problem, but not necessary the long term desired end-state. (I could be wrong about this though).
>
>
> The tests as-written seem to exercise the new functionality. I think it'd be fine to use the FileCheck-in-{dotest,lldbinline} support if you need to set a breakpoint, run a command, and then validate its output (though it looks like you don't)


Yea, once I need to actually run a process I expect I'll need to start using it.  For the time being, I'm trying see how much ground I can cover without a process.  The reasoning is two-fold.

First, it means the tests can run anywhere.  If there's no process, my test coverage isn't limited to a specific host OS.

Second, from a layering perspective, if I know that there's a ton of test coverage for "everything that happens before a process is spawned", then once you get to the point that you are spawning process, it limits the scope of where you have to search when something does go wrong.

So that's my thinking.


https://reviews.llvm.org/D53731