[Lldb-commits] [PATCH] D52618: [Windows] A basic implementation of memory allocations in a debuggee process

[Zachary Turner via lldb-commits]

Even in this exact case we have the multiple variants situation. If we use
the substitutions method we would reduce the test coverage by half, which
doesn’t seem like a good idea.

Similarly, in the target variables tests i added to the native pdb plugin
Jim was asking if I could also enable that exact same test for other
platforms. But it’s not possible without a way to run multiple variants.
And for tests where no running process is required I think it’s a worthy
goal to try to do that.
On Mon, Oct 29, 2018 at 6:04 AM Pavel Labath <pavel at labath.sk> wrote:

> On 26/10/18 18:34, Zachary Turner wrote:
> > I was thinking about this some more and I’m not sure simple
> > substitutions will suffice.
> >
> > We can provide substitutions to abstract away the command line, but that
> > doesn’t doesn’t really address the issue that we still need to have a
> > way to then run the the test program with each of the build outputs.
> > Keep in mind that it might take more than one compiler and/or linker
> > invocation to generate an output, and more than one lldb-test invocation
> > for the checks.
> >
> > The best idea I have for now is to split the check file into a common
> > file that everyone can share, but the lldb-test lines can be copied.  So
> > there is one .test file for windows, one for non windows, each with only
> > RUN lines, both sharing a common check file.
> >
> > I don’t think we should block this patch on coming up with something
> > more complicated than this though
> >
>
> The substitutions won't help if you're planning to run multiple variants
> of the same test (e.g. a DWARF and a PDB version) on all hosts. However,
> if you always just want to run a single version of the test (e.g., for
> the host), then it's enough to have a substitution which builds the
> given version of the executable.
>
> Given how the memory map tests are implemented right now (they require a
> running process, and they don't care too much about the details of how
> the debugee was built), this should be sufficient. I don't think we will
> ever have two flavours of these tests run in the same instance of the
> test suite, as it would require us the specify how to launch and debug
> an executable on multiple hosts.
>
> So, I'd recommend to stick with the substitution idea until we come up
> with something better.
>
> pl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181029/c65ea203/attachment.html>