<div dir="ltr">I was thinking of something along the lines of:<div><br></div><div><div>// SCRIPT-POSIX: posix/aggregate-indirect-arg.s<br></div><div>// SCRIPT-WIN: win/aggregate-indirect-arg.s</div><div><br></div><div>class SVal {</div><div>public:</div><div> ~SVal() {}</div><div> const void* Data;</div><div> unsigned Kind;</div><div>};</div><div><br></div><div>void bar(SVal &v) {}</div><div>class A {</div><div>public:</div><div> void foo(SVal v) { bar(v); }</div><div>};</div><div><br></div><div>int main() {</div><div> SVal v;</div><div> v.Data = 0;</div><div> v.Kind = 2142;</div><div> A a;</div><div> a.foo(v);</div><div> return 0;</div><div>}</div></div><div><br></div><div>Then, you could have:</div><div><br></div><div>// posix/aggregate-indirect-arg.s<br></div><div><br></div><div><div>// RUN: %clangxx %target_itanium_abi_host_triple -O0 -g %i -c -o %t.o</div><div>// RUN: %clangxx %target_itanium_abi_host_triple %t.o -o %t.out</div><div>// RUN: %test_debuginfo %s %t.out </div><div>// Radar 8945514</div><div>// DEBUGGER: break 22</div><div>// DEBUGGER: r</div><div>// DEBUGGER: p v</div><div>// CHECK: ${{[0-9]+}} =</div><div>// CHECK: Data ={{.*}} 0x0{{(0*)}}</div><div>// CHECK: Kind = 2142</div></div><div><br></div><div><br></div><div>// win/aggregate-indirect-arg.s</div><div><br></div><div><font size="2">// RUN: %clangcl /Z7 %i /c /Fo%t.obj</font></div><div><font size="2">// RUN: %lld-link /DEBUG %t.obj /out:%t.lld.exe</font></div><div><span style="font-size:small">// RUN: %run_windbg %t</span><span style="font-size:small">.lld</span><span style="font-size:small">.exe %s</span></div><div><font size="2">// RUN: %ms-link /DEBUG:FASTLINK %t.obj /out:%t.fastlink.exe</font></div><div><span style="font-size:small">// RUN: %run_windbg %t</span><span style="font-size:small">.fastlink</span><span style="font-size:small">.exe %s</span></div><div><font size="2">// DEBUGGER: bp 22</font></div><div><font size="2">// DEBUGGER: g</font></div><div><font size="2">// DEBUGGER: dt v</font></div><div><font size="2">// CHECK: Local var {{.*}} Type SVal</font></div><div><span style="font-size:small">// CHECK: </span><span style="font-size:small">+0x000 </span><span style="font-size:small">Data : (null) </span><br></div><div><font size="2">// CHECK: +0x004 Kind : 0x85e</font></div><div><font size="2"><br></font></div><div><font size="2">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.</font></div><div><font size="2"><br></font></div><div><font size="2">In rare cases where command lines, input, and output formats match up, just replace the SCRIPT-POSIX and SCRIPT-WIN directives with the actual run and check lines.</font></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 12:41 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Sep 7, 2017, at 12:31 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_-1030905140035953711Apple-interchange-newline"><div>That's true, but it still requires the person writing the test to be familiar with both formats. Also anything more trivial than dumping a single local variable will probably run into even more issues. <br><br>For example, The expression parsers each have their own unique quirks, and it might not always be easy to translate.<br></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>The vocabulary used by the tests is extremely limited, it is basically "b <line>", "r", "p <var>", "c", and twice "ptype" (which I would guess may be hard to support).</div>Do any of these lack an equivalent under WinDbg?</div><div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><br>Besides all the format compatibility issues, there's the more general issue that massaging one format into another format just introduces another place for things to go wrong and/or be flaky. But as we are the ones that have to do the massaging, we get the short end of the stick.<br><br>One possible bridge is to make some sort of special directive that identifies a certain fragment of the test file as gcc input & checks, and another directive that identifies windbg input & checks.<br></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>One way to implement this (especially if it only affects few tests) is to mark the test as unsupported under windows and then have a test script in, e.g., the pdb directory that has a new RUN command and CHECK lines but uses the same source code.</div><div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><br>This way each could have their own native run lines, debugger commands, and check statements, but share the same source code. The runner then chooses which mode to run based on which directives are present and whether a debugger to run the corresponding fragment in is found.<br></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>-- adrian</div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><br>This way you could have one or both directives in a file, and we'd run whichever version(s) are appropriate <br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 12:19 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Sep 7, 2017, at 12:11 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:</div><br class="m_-1030905140035953711m_-6419228888191256704Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><br class="m_-1030905140035953711m_-6419228888191256704Apple-interchange-newline">On Sep 7, 2017, at 12:01 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br class="m_-1030905140035953711m_-6419228888191256704Apple-interchange-newline"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 7, 2017 at 11:49 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-1030905140035953711m_-6419228888191256704m_1050070664503181110Apple-interchange-newline"><div><div dir="ltr">To be clear, the tests I'm proposing will have no resemblance whatsoever to GDB, so I would be intentionally forking the set of tests in this regards. So there would very clearly be a paradigm shift in writing CodeView debug info tests (which would be written in JavaScript using WinDbg specific debugger commands) and DWARF debug info tests (which would be written in whatever / using GDB style commands)</div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>That sounds like an unfortunate direction. Can you explain why it wouldn't be possible to write a wrapper (in JavaScript) that interprets the 3ish gdb commands used by the tests in terms of WinDbg? Similar to how LLDB is supported?</div><div><br></div></div></div></blockquote><div><br></div><div>I can think of a couple of reasons:</div><div><br></div><div>1) We're already going to need entirely different runlines. clang and clang-cl don't use the same command line options, or for that matter even styles.</div></div></div></div></blockquote><div><br></div>I'm not familiar with clang-cl so please bear with me if this is a stupid question: Is clang-cl just an MSVC compatible driver? Can you not produce the same result by using the "standard" clang driver and a windows target triple?</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>2) The output format is going to be different. whereas the current tests look for things like </div></div></div></div></blockquote><div><br></div>If you are going to write a wrapper script for the debugger commands, that wrapper script could also transform the output to look more like the GDB output that the CHECK-lines are looking for.<br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div><div>// CHECK: ${{[0-9]+}} =</div><div>// CHECK: Data ={{.*}} 0x0{{(0*)}}</div><div>// CHECK: Kind = 2142</div></div><div><br></div><div>In WinDbg this is going to be more like:</div><div><br></div><div><span style="color:rgb(30,30,30)">Local var @ 0x6ffa50 Type SVal</span><br></div><div><pre><span style="color:rgb(30,30,30)"> +0x000 </span><span style="color:rgb(30,30,30)">Data : (null) </span>
<span style="color:rgb(30,30,30)"> +0x004 </span><span style="color:rgb(30,30,30)">Kind : 0x85e</span></pre><pre><br></pre></div></div></div></div></blockquote></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Alternatively, this is still similar enough that we could relax the check to look like</div><div> CHECK: Data{{.*[:=].*(0x0|.null.)}}</div><div> CHECK: Kind{{.*[:=].*(2142|0x85e)}}</div><div>without much loss.</div></div><div style="word-wrap:break-word"><div><br></div><div>-- adrian</div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><pre><span style="font-family:sans-serif;white-space:normal">So we're also going to need different check lines.</span></pre><pre><font face="sans-serif"><span style="white-space:normal">At this point, the only similarities in the PDB / DWARF tests is going to be the source code, as I don't see an easy way to automatically translate command lines, input commands, and output text.</span></font></pre></div></div></div></div></blockquote></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">By the way, I'm fine with adding, e.g., a PDB subdirectory with a lit filter that contains tests that will only work under Windows, but it would be very unfortunate if there was no common set of tests, since then the Windows folks wouldn't benefit from new tests being added for GDB and vice versa.</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">-- adrian</div></div></blockquote></div><br></div></blockquote></div>
</div></blockquote></div></div></blockquote></div>