dblaikie added inline comments.
================
Comment at: lib/Driver/ToolChains/CommonArgs.cpp:813-830
+ if (Arg *A = Args.getLastArg(options::OPT_gsplit_dwarf_EQ))
+ if (StringRef(A->getValue()) == "single")
+ return Args.MakeArgString(Output.getFilename());
+
Arg *FinalOutput = Args.getLastArg(options::OPT_o);
if (FinalOutput && Args.hasArg(options::OPT_c)) {
SmallString<128> T(FinalOutput->getValue());
----------------
If this function now takes the output file name - could it be simplified to
just always use that, rather than the conditional code that follows and tests
whether -o is specified and builds up something like the output file name &
uses the dwo suffix?
================
Comment at: test/CodeGen/split-debug-single-file.c:12
+// RUN: -enable-split-dwarf=split -split-dwarf-file %t.o -emit-obj -o %t.o
%s
+// RUN: llvm-objdump -section-headers %t.o | FileCheck
--check-prefix=MODE-SPLIT %s
+// MODE-SPLIT-NOT: .dwo
----------------
This looks like an end-to-end test, which we don't usually do in Clang (or in
the LLVM project in general).
For example, the previous testing for split-dwarf had a driver test (that
tested only that the driver produced the right cc1 invocation) and a CodeGen
test (that tested that the right IR was produced), but I don't see any test
like this (that tested the resulting object file)?
I know there's a narrow gap in IR testing - things that don't go in the IR, but
instead go through MCOptions & that the SplitDwarfFile is one of those.
So, yeah, in this case it's a bit of a test hole - if you're going to keep this
test, perhaps it could test assembly, rather than the object file? Since it
doesn't need complex parsing, etc, perhaps?
https://reviews.llvm.org/D52296
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
