r174349 - Driver and option support for -gsplit-dwarf. This is a part of

[Eric Christopher]

> > +  ArgStringList ExtractArgs;
> > +  ExtractArgs.push_back("--extract-dwo");
> > +
> > +  ArgStringList StripArgs;
> > +  StripArgs.push_back("--strip-dwo");
>
> So objcopy itself (this isn't an LLVM tool but a system tool, right)
>

Correct.


> is dwo-aware? I assume this is a recent development alongside the
> DWARFv5 proposal? Are the test cases going to work on most systems
> that might not have such a bleeding edge objcopy?


Yes. Since the testcases don't actually run objcopy, just check to see that
if we were to run objcopy what would happen.


> What's the behavior
> like for users if their objcopy doesn't have this functionality?
>
>
It prints out a help error message from objcopy and exits.


> > +// REQUIRES: asserts
> > +// RUN: %clang -target x86_64-unknown-linux-gnu -ccc-print-phases \
> > +// RUN:   -gsplit-dwarf -arch x86_64 %s 2> %t
> > +// RUN: FileCheck -check-prefix=CHECK-ACTIONS < %t %s
>
> I'm not sure I've seen test cases written this way (with the file
> argument to FileCheck after the stdin specification) I assume it's
> more common to write it as "%s < %t" at the end? 'spose it doesn't
> matter though.
>
>
Enh. Cut and paste from the other similar testcases.


> > +//
> > +// CHECK-ACTIONS: 0: input, "{{.*}}split-debug.c", c
> > +// CHECK-ACTIONS: 4: split-debug, {3}, object
> > +
> > +// Check output name derivation.
> > +//
> > +// RUN: %clang -target x86_64-unknown-linux-gnu -ccc-print-bindings \
> > +// RUN:   -gsplit-dwarf -arch x86_64 -c %s 2> %t
> > +// RUN: FileCheck -check-prefix=CHECK-OUTPUT-NAME < %t %s
> > +//
> > +// CHECK-OUTPUT-NAME:# "x86_64-unknown-linux-gnu" - "clang", inputs:
> ["{{.*}}split-debug.c"], output: "{{.*}}split-debug{{.*}}.o"
> > +// CHECK-OUTPUT-NAME:# "x86_64-unknown-linux-gnu" -
> "linuxtools::SplitDebug", inputs: ["{{.*}}split-debug{{.*}}.o"], output:
> "{{.*}}split-debug{{.*}}.o"
>
> I don't see any mention of '.dwo' in this test case - does it verify
> that the dwo file is a product in any way?
>

*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.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130205/0799e08b/attachment.html>