<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
> +  ArgStringList ExtractArgs;<br>
> +  ExtractArgs.push_back("--extract-dwo");<br>
> +<br>
> +  ArgStringList StripArgs;<br>
> +  StripArgs.push_back("--strip-dwo");<br>
<br>
</div></div>So objcopy itself (this isn't an LLVM tool but a system tool, right)<br></blockquote><div><br></div><div style>Correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

is dwo-aware? I assume this is a recent development alongside the<br>
DWARFv5 proposal? Are the test cases going to work on most systems<br>
that might not have such a bleeding edge objcopy?</blockquote><div><br></div><div style>Yes. Since the testcases don't actually run objcopy, just check to see that if we were to run objcopy what would happen.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What's the behavior<br>
like for users if their objcopy doesn't have this functionality?<br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div style>It prints out a help error message from objcopy and exits.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
> +// REQUIRES: asserts<br>
> +// RUN: %clang -target x86_64-unknown-linux-gnu -ccc-print-phases \<br>
> +// RUN:   -gsplit-dwarf -arch x86_64 %s 2> %t<br>
> +// RUN: FileCheck -check-prefix=CHECK-ACTIONS < %t %s<br>
<br>
</div></div>I'm not sure I've seen test cases written this way (with the file<br>
argument to FileCheck after the stdin specification) I assume it's<br>
more common to write it as "%s < %t" at the end? 'spose it doesn't<br>
matter though.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Enh. Cut and paste from the other similar testcases.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> +//<br>
> +// CHECK-ACTIONS: 0: input, "{{.*}}split-debug.c", c<br>
> +// CHECK-ACTIONS: 4: split-debug, {3}, object<br>
> +<br>
> +// Check output name derivation.<br>
> +//<br>
> +// RUN: %clang -target x86_64-unknown-linux-gnu -ccc-print-bindings \<br>
> +// RUN:   -gsplit-dwarf -arch x86_64 -c %s 2> %t<br>
> +// RUN: FileCheck -check-prefix=CHECK-OUTPUT-NAME < %t %s<br>
> +//<br>
> +// CHECK-OUTPUT-NAME:# "x86_64-unknown-linux-gnu" - "clang", inputs: ["{{.*}}split-debug.c"], output: "{{.*}}split-debug{{.*}}.o"<br>
> +// CHECK-OUTPUT-NAME:# "x86_64-unknown-linux-gnu" - "linuxtools::SplitDebug", inputs: ["{{.*}}split-debug{{.*}}.o"], output: "{{.*}}split-debug{{.*}}.o"<br>
<br>
</div>I don't see any mention of '.dwo' in this test case - does it verify<br>
that the dwo file is a product in any way?<br></blockquote><div><br></div><div style>*sigh* Figured you'd notice this. So what's fun and annoyingly limiting is that you can't have two products from an individual action and in order to keep the "please use this as input to the link step" I have to ignore that the .dwo file exists as an output and rely that it's a happy side-effect. I'm totally open to better ideas here.</div>
<div style><br></div><div style>-eric</div></div></div></div>