[llvm-dev] Status of debuginfo-tests

Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 8 09:00:29 PDT 2017

> On Sep 7, 2017, at 1:15 PM, Zachary Turner <zturner at google.com> wrote:
> I was thinking of something along the lines of:
> // SCRIPT-POSIX: posix/aggregate-indirect-arg.s
> // SCRIPT-WIN: win/aggregate-indirect-arg.s
> class SVal {
> public:
>   ~SVal() {}
>   const void* Data;
>   unsigned Kind;
> };
> void bar(SVal &v) {}
> class A {
> public:
>   void foo(SVal v) { bar(v); }
> };
> int main() {
>   SVal v;
>   v.Data = 0;
>   v.Kind = 2142;
>   A a;
>   a.foo(v);
>   return 0;
> }
> Then, you could have:
> // posix/aggregate-indirect-arg.s
> // RUN: %clangxx %target_itanium_abi_host_triple -O0 -g %i   -c -o %t.o
> // RUN: %clangxx %target_itanium_abi_host_triple %t.o -o %t.out
> // RUN: %test_debuginfo %s  %t.out 
> // Radar 8945514
> // DEBUGGER: break 22
> // DEBUGGER: r
> // DEBUGGER: p v
> // CHECK: ${{[0-9]+}} =
> // CHECK:  Data ={{.*}} 0x0{{(0*)}}
> // CHECK:  Kind = 2142
> // win/aggregate-indirect-arg.s
> // RUN: %clangcl /Z7 %i /c /Fo%t.obj
> // RUN: %lld-link /DEBUG %t.obj /out:%t.lld.exe
> // RUN: %run_windbg %t.lld.exe %s
> // RUN: %ms-link /DEBUG:FASTLINK %t.obj /out:%t.fastlink.exe
> // RUN: %run_windbg %t.fastlink.exe %s
> // DEBUGGER: bp 22
> // DEBUGGER: g
> // DEBUGGER: dt v
> // CHECK: Local var {{.*}} Type SVal
> // CHECK:  +0x000 Data : (null) 
> // CHECK: +0x004 Kind : 0x85e
> Eventually, some tests will inevitably need to Windows or Posix specific, so you're going to have to have all this extra stuff (the new substitutions, the different command lines, the custom output formats, etc.  So I think something like this provides maximal encouragement of sharing whenever possible (since you can almost always share source code), while still allowing each format to test real input and real output.

I understand the desire to allow for Windows-specific tests and I think it would be good to add them to the repository in a windows subdirectory.

Looking at the example you posted, the two variants are so structurally similar that I believe it would be a better to come up with a common abstraction from a readability / maintenance effort perspective. Basically, the only thing that the RUN lines do is compile and link executables from source code using the default target and run the test_debuginfo command. I think it would be better to define a new command substitution %clang-compile-link(?) in LIT that has different implementations on windows and posix. The set of debugger commands used by the tests is so tiny that it should not be a lot of work to implement a wrapper for the windows debugger (it took me about a day to write the python wrapper for LLDB including learning how to use the Python API) and it should also be possible to either do a sed-style massaging of the output or relax the CHECKs to work with both formats.

I really want to avoid duplicating the debugger commands and checks, and I also want to maintain the ability to put the commands and CHECKs into the source code, since this makes the tests much easier to understand. Using a common abstraction will save us a lot of time in the long run, make maintenance and adding new tests cheaper, and won't prevent you from also having windows-specific tests that may use an expanded vocabulary.

What do you think?
-- adrian

More information about the llvm-dev mailing list