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

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

I think we should try as hard as possible to have just one way of writing these tests.  So if we know there are going to be two different use cases, one where we have mutually exclusive variants (e.g. run a process on OSX, Linux, Windows), and platform agnostic variants (compile for multiple platform / debug info variants, run tests in every possible configuration), I think we should try to unify all of these under a single syntax.

One possible syntax that works today is to duplicate all the compile and test lines but delegate to an external check file.

  ; file 1
  ; REQUIRES: windows
  ; RUN: clang-cl ...
  ; RUN: lld-link ...
  ; RUN: lldb-test | FileCheck --check-file=%p/Inputs/some-test.check
  
  ; file 2
  ; UNSUPPORTED: windows
  ; RUN: clang++ ...
  ; RUN: lldb-test | FileCheck --check-file=%p/Inputs/some-test.check

This unblocks the patch, doesn't require any fancy logic that would be unfamiliar with people coming to LLDB, and is pretty simple.

I think we can do better than the above by removing the need to have multiple files, but the substitutions only get us halfway there because they don't handle the case where we actually want to repeat the same test multiple times with different command lines.  So since we're going to have to fall back to the above approach for that, let's just do it everywhere until we can come up with a solution that unifies everything under one syntax.

FWIW, I've been brainstorming some modifications to the core lit infrastructure that would support this kind of thing.  Here's some strawman syntax:

  VARIANTS: v1, v2
  
  REQUIRES-v1: windows
  UNSUPPORTED-v2: windows
  
  RUN-v1: %cxx %p/Inputs/call-function.cpp -g -o %t
  RUN-v2: clang-cl /Zi %p/Inputs/call-function.cpp -o %t
  
  RUN: lldb-test ir-memory-map %t %S/Inputs/ir-memory-map-basic
  RUN: lldb-test ir-memory-map -host-only %t %S/Inputs/ir-memory-map-basic
  
  RUN: lldb-test ir-memory-map %t %S/Inputs/ir-memory-map-overlap1
  RUN: lldb-test ir-memory-map -host-only %t %S/Inputs/ir-memory-map-overlap1
  
  RUN: lldb-test ir-memory-map %t %S/Inputs/ir-memory-map-mix-malloc-free
  RUN: lldb-test ir-memory-map -host-only %t %S/Inputs/ir-memory-map-mix-malloc-free

Now in this case the two variants are mutually exclusive, but they need not be.  So, for example, in the case of my target variables test for builtin types, which I wrote as this:

  // Test that we can display tag types.
  // RUN: clang-cl /Z7 /GS- /GR- /c -Xclang -fkeep-static-consts /Fo%t.obj -- %s
  // RUN: lld-link /DEBUG /nodefaultlib /entry:main /OUT:%t.exe /PDB:%t.pdb -- %t.obj
  // RUN: env LLDB_USE_NATIVE_PDB_READER=1 lldb -f %t.exe -s \
  // RUN:     %p/Inputs/globals-fundamental.lldbinit | FileCheck %s
  
  // bunch of source code

We could re-write it as:

  // VARIANTS: v1, v2
  
  // RUN-v1: clang-cl /Z7 /GS- /GR- /c -Xclang -fkeep-static-consts /Fo%t.obj -- %s
  // RUN-v1: lld-link /DEBUG /nodefaultlib /entry:main /OUT:%t.exe /PDB:%t.pdb -- %t.obj
  // RUN-v1: env LLDB_USE_NATIVE_PDB_READER=1 lldb -f %t.exe -s \
  // RUN-v1:     %p/Inputs/globals-fundamental.lldbinit | FileCheck %s
  // RUN-v2: clang++ -g -m64 -Xclang -fkeep-static-consts --target=x86_x64-linux-gnu -o %t -- %s
  // RUN-v2: lldb -f %t -s %p/Inputs/globals-fundamental.lldbinit | FileCheck %s
  
  // bunch of source code

This will run variant 1, then run variant 2.

I think this fits nicely with the lit "philosophy" and handles all the use cases that we need.  But there's a lot of detail in implementing it correctly (and right now it's just in my head, I'm not actually working on it).  So I think we should go with the simple thing for now of just having 2 files and one shared check file so that we can unblock the patch and make forward progress


https://reviews.llvm.org/D52618