[Lldb-commits] [PATCH] D52618: [Windows] A basic implementation of memory allocations in a debuggee process
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Mon Oct 29 07:06:50 PDT 2018
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits