[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
echristo added a comment.
In https://reviews.llvm.org/D52296#1285328, @grimar wrote:
> In https://reviews.llvm.org/D52296#1284130, @probinson wrote:
>
> > In https://reviews.llvm.org/D52296#1283691, @grimar wrote:
> >
> > > Nice :)
> > > So seems the last unresolved question left is the naming of the new
> > > option?
> > > If we do not want to go with `-gsingle-file-split-dwarf` then what it
> > > should be?
> > >
> > > What about `-fdebug-fission` as an alias for `-gsplit-dwarf`.
> > > And `-fsingle-file-debug-fission` for the new option?
> > >
> > > Or, may be:
> > >
> > > `-fdebug-fission` for the new option and then
> > > `-fdebug-fission -fdebug-split-dwo` would work together as
> > > `-gsplit-dwarf`?
> >
> >
> > Only DWARF supports this, correct?
>
>
> I am not aware of any kind of debug information splitting except DWARF
> splitting.
>
> > So I would suggest: `-fdwarf-fission[={split,single}]` where the parameter
> > defaults to `split`. Is there any particular value in having two separate
> > options?
>
> Probably not. `-fdwarf-fission[={split,single}]` sounds good for me.
Still not sure I understand the point, but this option and the alias sounds
good to me.
Thanks.
-eric
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment.
In https://reviews.llvm.org/D52296#1284130, @probinson wrote:
> In https://reviews.llvm.org/D52296#1283691, @grimar wrote:
>
> > Nice :)
> > So seems the last unresolved question left is the naming of the new option?
> > If we do not want to go with `-gsingle-file-split-dwarf` then what it
> > should be?
> >
> > What about `-fdebug-fission` as an alias for `-gsplit-dwarf`.
> > And `-fsingle-file-debug-fission` for the new option?
> >
> > Or, may be:
> >
> > `-fdebug-fission` for the new option and then
> > `-fdebug-fission -fdebug-split-dwo` would work together as `-gsplit-dwarf`?
>
>
> Only DWARF supports this, correct?
I am not aware of any kind of debug information splitting except DWARF
splitting.
> So I would suggest: `-fdwarf-fission[={split,single}]` where the parameter
> defaults to `split`. Is there any particular value in having two separate
> options?
Probably not. `-fdwarf-fission[={split,single}]` sounds good for me.
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
probinson added a comment.
In https://reviews.llvm.org/D52296#1283691, @grimar wrote:
> Nice :)
> So seems the last unresolved question left is the naming of the new option?
> If we do not want to go with `-gsingle-file-split-dwarf` then what it should
> be?
>
> What about `-fdebug-fission` as an alias for `-gsplit-dwarf`.
> And `-fsingle-file-debug-fission` for the new option?
>
> Or, may be:
>
> `-fdebug-fission` for the new option and then
> `-fdebug-fission -fdebug-split-dwo` would work together as `-gsplit-dwarf`?
Only DWARF supports this, correct? So I would suggest:
`-fdwarf-fission[={split,single}]` where the parameter defaults to `split`. Is
there any particular value in having two separate options?
https://reviews.llvm.org/D52296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. Nice :) So seems the last unresolved question left is the naming of the new option? If we do not want to go with `-gsingle-file-split-dwarf` then what it should be? What about `-fdebug-fission` as an alias for `-gsplit-dwarf`. And `-fsingle-file-debug-fission` for the new option? Or, may be: `-fdebug-fission` for the new option and then `-fdebug-fission -fdebug-split-dwo` would work together as `-gsplit-dwarf`? https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
dblaikie added a comment. In https://reviews.llvm.org/D52296#1282603, @probinson wrote: > In https://reviews.llvm.org/D52296#1282589, @dblaikie wrote: > > > In https://reviews.llvm.org/D52296#1282587, @probinson wrote: > > > > > Any distributed build has to make this work, so the paths in the line > > > table are usable. Not clear what you're thinking might be the problem > > > with the split-in-.o case. > > > > > > Fair point - same sort of problem, but might need distinct handling (ie: > > might not work "for free" with existing tools, but need more support), etc, > > depending on how it's solved? > > > > Mostly just wondering whether Clang would need extra flags to support this > > - to get a sense of the total/overall solution/surface area of the feature, > > etc. > > > Shouldn't. We have licensees using distributed builds all day every day, but > we haven't introduced anything into the compiler itself to make that work. > On Windows, I know SN-DBS will intercept system calls to patch up filespecs. > On Linux I'd expect the remote servers to set up chroot environments so the > path names will Just Work, although I admit I've never actually looked. > Never had to; it Just Works. Neat! > In this patch, where the .o normally points to the .dwo it would instead just > point to itself, right? Right - that's an absolute path, like the line table (between dir+name, if you don't override the base dir to something else, etc). So, yeah, if the solutions for that are implemented at a sufficiently low level as you've described above, sounds like there's a good chance it'd Just Work for this part too. > The linker doesn't need to fix anything up, it just ignores the .dwo > sections. *nod* Not suggesting the linker could/would be able to fix anything up here - but that the compiler might need extra command line features to help ensure the values were written in a way that was useful. For example, I believe the Chromium build system may use -fdebug-compilation-dir and -fdebug-prefix-map to make cached distributed builds work (where it'd be impossible to bake in any particular path - because two users may be building Chromium from different locations, but they should be able to share build artefacts for maximal caching). But if that's not the usual problem/solution (or there are sufficiently many users/use cases that don't have that problem) - that's cool & it's nice if this just works for those users - and if, for whatever reason, that a Chromium-like situation comes up & wants non-split-split-DWARF & needs to address the problem, we can cross that bridge at that time (either by using the existing properties (like -fdebug-compilation-dir and -fdebug-prefix-map) if they provide enough information, or by adding other flags to that family to allow the user to do so) https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
probinson added a comment. In https://reviews.llvm.org/D52296#1282589, @dblaikie wrote: > In https://reviews.llvm.org/D52296#1282587, @probinson wrote: > > > Any distributed build has to make this work, so the paths in the line table > > are usable. Not clear what you're thinking might be the problem with the > > split-in-.o case. > > > Fair point - same sort of problem, but might need distinct handling (ie: > might not work "for free" with existing tools, but need more support), etc, > depending on how it's solved? > > Mostly just wondering whether Clang would need extra flags to support this - > to get a sense of the total/overall solution/surface area of the feature, etc. Shouldn't. We have licensees using distributed builds all day every day, but we haven't introduced anything into the compiler itself to make that work. On Windows, I know SN-DBS will intercept system calls to patch up filespecs. On Linux I'd expect the remote servers to set up chroot environments so the path names will Just Work, although I admit I've never actually looked. Never had to; it Just Works. In this patch, where the .o normally points to the .dwo it would instead just point to itself, right? The linker doesn't need to fix anything up, it just ignores the .dwo sections. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
dblaikie added a comment. In https://reviews.llvm.org/D52296#1282587, @probinson wrote: > In https://reviews.llvm.org/D52296#1282458, @dblaikie wrote: > > > I guess in that case your distributed build system would have a constraint > > that it always ships all the object files back to the primary machine > > (where you'd be running the debugger)? (perhaps it just always runs the > > link locally - even though it distributes the compilations - I guess that's > > probably how things like distcc work, where they only inject themselves > > into the compilation command, not the linking command maybe?) > > > AFAIK this is how distcc, icecc, SN-DBS all work. Compilations are > distributed, the .o files come back, links are local. Thanks! I've never used them, so was just guessing/estimating. > > >> Also, may require some work/more flags to handle the possible file renaming >> (or relative/absolute adjustment) when object files are built on a remote >> system in one location, but then moved back to the local system and placed >> in another location? > > Any distributed build has to make this work, so the paths in the line table > are usable. Not clear what you're thinking might be the problem with the > split-in-.o case. Fair point - same sort of problem, but might need distinct handling (ie: might not work "for free" with existing tools, but need more support), etc, depending on how it's solved? Mostly just wondering whether Clang would need extra flags to support this - to get a sense of the total/overall solution/surface area of the feature, etc. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
probinson added a comment. In https://reviews.llvm.org/D52296#1282458, @dblaikie wrote: > I guess in that case your distributed build system would have a constraint > that it always ships all the object files back to the primary machine (where > you'd be running the debugger)? (perhaps it just always runs the link locally > - even though it distributes the compilations - I guess that's probably how > things like distcc work, where they only inject themselves into the > compilation command, not the linking command maybe?) AFAIK this is how distcc, icecc, SN-DBS all work. Compilations are distributed, the .o files come back, links are local. > Also, may require some work/more flags to handle the possible file renaming > (or relative/absolute adjustment) when object files are built on a remote > system in one location, but then moved back to the local system and placed in > another location? Any distributed build has to make this work, so the paths in the line table are usable. Not clear what you're thinking might be the problem with the split-in-.o case. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
dblaikie added a comment. In https://reviews.llvm.org/D52296#1282369, @grimar wrote: > In https://reviews.llvm.org/D52296#1281642, @echristo wrote: > > > Can you elaborate on your motivations and what you're trying to do? > > > > Thanks! > > > We want to see: > > - No extra files. The compiler produces just a .o. > - The linker leaves most debug info in the .o files. > > That makes the build friendly to existing tools and avoids most of the > static linker work. I guess in that case your distributed build system would have a constraint that it always ships all the object files back to the primary machine (where you'd be running the debugger)? (perhaps it just always runs the link locally - even though it distributes the compilations - I guess that's probably how things like distcc work, where they only inject themselves into the compilation command, not the linking command maybe?) Also, may require some work/more flags to handle the possible file renaming (or relative/absolute adjustment) when object files are built on a remote system in one location, but then moved back to the local system and placed in another location? https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. In https://reviews.llvm.org/D52296#1281642, @echristo wrote: > Can you elaborate on your motivations and what you're trying to do? > > Thanks! We want to see: - No extra files. The compiler produces just a .o. - The linker leaves most debug info in the .o files. That makes the build friendly to existing tools and avoids most of the static linker work. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
echristo added a comment. In https://reviews.llvm.org/D52296#1246142, @grimar wrote: > In https://reviews.llvm.org/D52296#1243688, @echristo wrote: > > > In https://reviews.llvm.org/D52296#1241928, @probinson wrote: > > > > > Do we generate the .dwo file directly these days? If not, I can imagine > > > wanting to avoid the overhead of the objcopy hack; as long as the linker > > > is smart enough not to bother with the .debug_*.dwo sections this seems > > > like a build-time win. > > > > > > We do generate them generically with no objcopy hack. > > > Eric, could you elaborate for me your position, please We don't use objcopy on linux or fuschia to generate .dwo files. > > >> As far as the standard text here, IMO it was just there in case people >> didn't have an objcopy around or don't want to split it. > > Yeah, we do not want to split it and I see no other way to say clang to keep > them in a .o files rather than introducing the new flag. > Am I missing something? > >> I'm not sure why we would want the ability. >> That said, if we do I'd rather have it as dwarf5 without split-dwarf as an >> option rather than a -gsingle-file-split-dwarf option. > > What do you mean as "dwarf5 without split-dwarf as an option" here? Do you > mean to do split-dwarf by default? It is orthogonal to what this patch does. So, what are you trying to do here is, I guess, my other question. Are you trying to take advantage of dwarf5 features, or are you just trying to have everything in one file for later splitting? Or something else? If you want to generate split dwarf (as opposed to a lot of dwarf5 features some of which are split dwarf) I'll bike shed that we need to come up with a better set of option naming here - I'd probably repurpose/alias -gsplit-dwarf and use -f options for whether or not to use specific features etc. Can you elaborate on your motivations and what you're trying to do? Thanks! https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar updated this revision to Diff 171480.
grimar added a comment.
Ping.
- Rebased.
https://reviews.llvm.org/D52296
Files:
include/clang/Driver/CC1Options.td
include/clang/Driver/Options.td
include/clang/Frontend/CodeGenOptions.h
lib/CodeGen/BackendUtil.cpp
lib/Driver/ToolChains/Clang.cpp
lib/Driver/ToolChains/CommonArgs.cpp
lib/Driver/ToolChains/CommonArgs.h
lib/Driver/ToolChains/Gnu.cpp
lib/Driver/ToolChains/MinGW.cpp
lib/Frontend/CompilerInvocation.cpp
test/CodeGen/split-debug-single-file.c
test/Driver/split-debug.c
test/Driver/split-debug.s
Index: test/Driver/split-debug.s
===
--- test/Driver/split-debug.s
+++ test/Driver/split-debug.s
@@ -5,6 +5,9 @@
//
// CHECK-ACTIONS: "-split-dwarf-file" "split-debug.dwo"
+// Check we do not pass any -split-dwarf commands to `as` if -gsingle-file-split-dwarf is specified.
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gsingle-file-split-dwarf -c -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
// RUN: %clang -target x86_64-macosx -gsplit-dwarf -c -### %s 2> %t
// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
Index: test/Driver/split-debug.c
===
--- test/Driver/split-debug.c
+++ test/Driver/split-debug.c
@@ -5,6 +5,16 @@
//
// CHECK-ACTIONS: "-split-dwarf-file" "split-debug.dwo"
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gsingle-file-split-dwarf -c -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-ACTIONS-SINGLE-SPLIT < %t %s
+//
+// CHECK-ACTIONS-SINGLE-SPLIT: "-single-file-split-dwarf"
+// CHECK-ACTIONS-SINGLE-SPLIT: "-split-dwarf-file" "split-debug.o"
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gsingle-file-split-dwarf -c -### -o %tfoo.o %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-SINGLE-SPLIT-FILENAME < %t %s
+//
+// CHECK-SINGLE-SPLIT-FILENAME: "-split-dwarf-file" "{{.*}}foo.o"
// RUN: %clang -target x86_64-macosx -gsplit-dwarf -c -### %s 2> %t
// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
Index: test/CodeGen/split-debug-single-file.c
===
--- test/CodeGen/split-debug-single-file.c
+++ test/CodeGen/split-debug-single-file.c
@@ -0,0 +1,16 @@
+// REQUIRES: x86-registered-target
+
+// Testing to ensure -single-file-split-dwarf allows to place .dwo sections into regular output object.
+// RUN: %clang_cc1 -debug-info-kind=limited -triple x86_64-unknown-linux \
+// RUN: -enable-split-dwarf -split-dwarf-file %t.o -emit-obj -single-file-split-dwarf -o %t.o %s
+// RUN: llvm-objdump -section-headers %t.o | FileCheck --check-prefix=SINGLE-FILE-SPLIT %s
+// SINGLE-FILE-SPLIT: .dwo
+
+// Testing to ensure that the dwo name gets output into the compile unit.
+// RUN: %clang_cc1 -debug-info-kind=limited -split-dwarf-file foo.o -single-file-split-dwarf \
+// RUN: -S -emit-llvm -o - %s | FileCheck %s --check-prefix=DWONAME
+// DWONAME: !DICompileUnit({{.*}}, splitDebugFilename: "foo.o"
+
+int main (void) {
+ return 0;
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -598,6 +598,8 @@
Opts.EnableSplitDwarf = Args.hasArg(OPT_enable_split_dwarf);
Opts.SplitDwarfFile = Args.getLastArgValue(OPT_split_dwarf_file);
Opts.SplitDwarfInlining = !Args.hasArg(OPT_fno_split_dwarf_inlining);
+ Opts.SingleFileSplitDwarf = Args.hasArg(OPT_single_file_split_dwarf);
+
Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
Opts.DebugExplicitImport = Args.hasArg(OPT_dwarf_explicit_import);
Opts.DebugFwdTemplateParams = Args.hasArg(OPT_debug_forward_template_params);
Index: lib/Driver/ToolChains/MinGW.cpp
===
--- lib/Driver/ToolChains/MinGW.cpp
+++ lib/Driver/ToolChains/MinGW.cpp
@@ -54,7 +54,7 @@
if (Args.hasArg(options::OPT_gsplit_dwarf))
SplitDebugInfo(getToolChain(), C, *this, JA, Args, Output,
- SplitDebugName(Args, Inputs[0]));
+ SplitDebugName(Args, Inputs[0], Output));
}
void tools::MinGW::Linker::AddLibGCC(const ArgList ,
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -817,7 +817,7 @@
if (Args.hasArg(options::OPT_gsplit_dwarf) &&
getToolChain().getTriple().isOSLinux())
SplitDebugInfo(getToolChain(), C, *this, JA, Args, Output,
- SplitDebugName(Args, Inputs[0]));
+ SplitDebugName(Args, Inputs[0], Output));
}
namespace {
Index: lib/Driver/ToolChains/CommonArgs.h
===
--- lib/Driver/ToolChains/CommonArgs.h
+++
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
dblaikie added a comment. In https://reviews.llvm.org/D52296#1272220, @grimar wrote: > Maybe `-gno-dwo`? So we would write `-genable-split-dwarf -gno-dwo`? I'm not sure how everyone else feels about "-g" flags that modify debug behavior (like "-gsplit-dwarf") versus "-f" flags (eg: "-fdebug-types-section"). I kind of personally feel like "-g" flags are a bit odd & would think -f flags to modify debug info behavior, leaving "-g" mostly to turn on/off debug info (so, -g, -gN, -gmlt, etc - sort of like -O, -ON, -Os, etc). by that logic -funsplit-split-dwarf ? Mostly goofy suggestion, vaguely trolling @echristo to see if he's got other/better ideas, or clearer feelings/understanding of history around the flag naming conventions (-f, -g, broad naming in general, etc). https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. Maybe `-gno-dwo`? So we would write `-genable-split-dwarf -gno-dwo`? https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
dblaikie added a comment. @echristo > As far as the standard text here, IMO it was just there in case people didn't > have an objcopy around or don't want to split it. I'm not sure why we would > want the ability. I think others have mentioned - but with distributed build it might be easier to keep it as a single file because your build system already knows how to ship around those files. > That said, if we do I'd rather have it as dwarf5 without split-dwarf as an > option rather than a -gsingle-file-split-dwarf option. Any suggestions on the name? https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
alexshap added a comment. I talked to David @dblaikie offline about this diff yesterday, if I understood correctly this change is reasonable in general, @echristo Eric, would you mind having a look at this diff ? https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
alexshap added a comment. Ping https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
alexshap added a comment. I see, many thanks. I've cherry-picked this patch locally and played with GDB - it appears to work fine with it. I'm also interested and support this change since this would simplify the adoption of Fission by some build systems. @dblaikie, @echristo - are there any particular concerns with moving this forward ? https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. In https://reviews.llvm.org/D52296#1258677, @alexshap wrote: > @grimar, this is an interesting observation which I've had on my mind for > quite some time as well; a couple of things which I have not double-checked > yet - just in case - do both gold and lld completely ignore dwo-related > sections ? (did you check that ?), LLVM emits them with the SHF_EXCLUDE flag since the https://reviews.llvm.org/rL342800 "[lib/MC] - Set SHF_EXCLUDE flag for .dwo sections.". So if linker supports SHF_EXCLUDE flag properly, it will ignore it properly. That is true for bfd/gold/LLD atm. LLD does not ignore ".dwo" sections by name and I do not expect other linkers do (and that is fine, we do not want to ignore sections by name generally), so having this flag is an important and clean thing for things to work. > and another small question - just wondering if the debuggers (GDB and LLDB) > are okay with it / or smth needs to be adjusted or fixed on their side. I > guess everything should be fine, but asking just in case. The patch for LLDB is ready to be landed: https://reviews.llvm.org/D52403. It waits for this one, since its test case mentions/uses -gsingle-file-split-dwarf option. I am thinking about rewriting the comment and landing it independently. I did not check the GDB yet. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
alexshap added a comment. @grimar, this is an interesting observation which I've had on my mind for quite some time as well; a couple of things which I have not double-checked yet - just in case - do both gold and lld completely ignore dwo-related sections ? (did you check that ?), and another small question - just wondering if the debuggers (GDB and LLDB) are okay with it / or smth needs to be adjusted or fixed on their side. I guess everything should be fine, but asking just in case. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. Ping. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. Ping. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. In https://reviews.llvm.org/D52296#1243688, @echristo wrote: > In https://reviews.llvm.org/D52296#1241928, @probinson wrote: > > > Do we generate the .dwo file directly these days? If not, I can imagine > > wanting to avoid the overhead of the objcopy hack; as long as the linker is > > smart enough not to bother with the .debug_*.dwo sections this seems like a > > build-time win. > > > We do generate them generically with no objcopy hack. Eric, could you elaborate for me your position, please > As far as the standard text here, IMO it was just there in case people didn't > have an objcopy around or don't want to split it. Yeah, we do not want to split it and I see no other way to say clang to keep them in a .o files rather than introducing the new flag. Am I missing something? > I'm not sure why we would want the ability. > That said, if we do I'd rather have it as dwarf5 without split-dwarf as an > option rather than a -gsingle-file-split-dwarf option. What do you mean as "dwarf5 without split-dwarf as an option" here? Do you mean to do split-dwarf by default? It is orthogonal to what this patch does. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
echristo added a comment. In https://reviews.llvm.org/D52296#1241928, @probinson wrote: > Do we generate the .dwo file directly these days? If not, I can imagine > wanting to avoid the overhead of the objcopy hack; as long as the linker is > smart enough not to bother with the .debug_*.dwo sections this seems like a > build-time win. We do generate them generically with no objcopy hack. As far as the standard text here, IMO it was just there in case people didn't have an objcopy around or don't want to split it. I'm not sure why we would want the ability. That said, if we do I'd rather have it as dwarf5 without split-dwarf as an option rather than a -gsingle-file-split-dwarf option. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
echristo added a comment. In https://reviews.llvm.org/D52296#1241928, @probinson wrote: > Do we generate the .dwo file directly these days? If not, I can imagine > wanting to avoid the overhead of the objcopy hack; as long as the linker is > smart enough not to bother with the .debug_*.dwo sections this seems like a > build-time win. We do generate them generically with no objcopy hack. As far as the standard text here, IMO it was just there in case people didn't have an objcopy around or don't want to split it. I'm not sure why we would want the ability. That said, if we do I'd rather have it as dwarf5 without split-dwarf as an option rather than a -gsingle-file-split-dwarf option. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. To summarise: - It shares most of the benefits with the .dwo solution. - Unlike .dwo, there is no need to split the file and it is friendlier to other tools (ccache, distcc, etc) - But unlike .dwo a distributed build system has to copy larger .o files. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar added a comment. We want to take the benefit that debug fission provides, but keep the debug information in the objects. That is a bit less intrusive way than using regular split dwarf flow. For a regular build and debug cycle that allows the linker to do minimal processing of the .debug_str. Since .debug_str.dwo is ignored, that allows to significantly reduce the link time, as strings processing is slow and string sections are large by themselves to handle them. And at the same time the build system still does not see anything unusual/strange as it sees only .o files like it is just a regular non-split-dwarf flow. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
probinson added a comment. Do we generate the .dwo file directly these days? If not, I can imagine wanting to avoid the overhead of the objcopy hack; as long as the linker is smart enough not to bother with the .debug_*.dwo sections this seems like a build-time win. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
dblaikie added a comment. Do you/what's your particular use case for this scenario? I guess this looks a bit like Apple's format (where debug info stays in the object file and isn't linked into the final binary), but don't expect they'd be moving to this any time soon. https://reviews.llvm.org/D52296 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D52296: [Clang] - Add -gsingle-file-split-dwarf option.
grimar created this revision.
grimar added reviewers: dblaikie, echristo, probinson, compnerd.
Herald added subscribers: JDevlieghere, aprantl.
The DWARF5 specification says(Appendix F.1):
"The sections that do not require relocation, however, **can be written to the
relocatable object (.o) file but ignored by the
linker** or they can be written to a separate DWARF object (.dwo) file that
need not be accessed by the linker."
The first part describes a single file split DWARF feature and there is no way
to trigger this behavior atm I think.
Fortunately, no many changes are required to keep *.dwo sections in a .o, the
patch does that.
Not sure who is an appropriate reviewer for that.
https://reviews.llvm.org/D52296
Files:
include/clang/Driver/CC1Options.td
include/clang/Driver/Options.td
include/clang/Frontend/CodeGenOptions.h
lib/CodeGen/BackendUtil.cpp
lib/Driver/ToolChains/Clang.cpp
lib/Driver/ToolChains/CommonArgs.cpp
lib/Driver/ToolChains/CommonArgs.h
lib/Driver/ToolChains/Gnu.cpp
lib/Driver/ToolChains/MinGW.cpp
lib/Frontend/CompilerInvocation.cpp
test/CodeGen/split-debug-single-file.c
test/Driver/split-debug.c
test/Driver/split-debug.s
Index: test/Driver/split-debug.s
===
--- test/Driver/split-debug.s
+++ test/Driver/split-debug.s
@@ -5,6 +5,9 @@
//
// CHECK-ACTIONS: "-split-dwarf-file" "split-debug.dwo"
+// Check we do not pass any -split-dwarf commands to `as` if -gsingle-file-split-dwarf is specified.
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gsingle-file-split-dwarf -c -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
// RUN: %clang -target x86_64-macosx -gsplit-dwarf -c -### %s 2> %t
// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
Index: test/Driver/split-debug.c
===
--- test/Driver/split-debug.c
+++ test/Driver/split-debug.c
@@ -5,6 +5,17 @@
//
// CHECK-ACTIONS: "-split-dwarf-file" "split-debug.dwo"
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gsingle-file-split-dwarf -c -### %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-ACTIONS-SINGLE-SPLIT < %t %s
+//
+// CHECK-ACTIONS-SINGLE-SPLIT: "-single-file-split-dwarf"
+// CHECK-ACTIONS-SINGLE-SPLIT: "-split-dwarf-file" "split-debug.o"
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gsingle-file-split-dwarf -c -### -o %tfoo.o %s 2> %t
+// RUN: FileCheck -check-prefix=CHECK-SINGLE-SPLIT-FILENAME < %t %s
+//
+// CHECK-SINGLE-SPLIT-FILENAME: "-split-dwarf-file" "{{.*}}foo.o"
+
// RUN: %clang -target x86_64-macosx -gsplit-dwarf -c -### %s 2> %t
// RUN: FileCheck -check-prefix=CHECK-NO-ACTIONS < %t %s
Index: test/CodeGen/split-debug-single-file.c
===
--- test/CodeGen/split-debug-single-file.c
+++ test/CodeGen/split-debug-single-file.c
@@ -0,0 +1,16 @@
+// REQUIRES: x86-registered-target
+
+// Testing to ensure -single-file-split-dwarf allows to place .dwo sections into regular output object.
+// RUN: %clang_cc1 -debug-info-kind=limited -triple x86_64-unknown-linux \
+// RUN: -enable-split-dwarf -split-dwarf-file %t.o -emit-obj -single-file-split-dwarf -o %t.o %s
+// RUN: llvm-objdump -section-headers %t.o | FileCheck --check-prefix=SINGLE-FILE-SPLIT %s
+// SINGLE-FILE-SPLIT: .dwo
+
+// Testing to ensure that the dwo name gets output into the compile unit.
+// RUN: %clang_cc1 -debug-info-kind=limited -split-dwarf-file foo.o -single-file-split-dwarf \
+// RUN: -S -emit-llvm -o - %s | FileCheck %s --check-prefix=DWONAME
+// DWONAME: !DICompileUnit({{.*}}, splitDebugFilename: "foo.o"
+
+int main (void) {
+ return 0;
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -597,6 +597,8 @@
Opts.EnableSplitDwarf = Args.hasArg(OPT_enable_split_dwarf);
Opts.SplitDwarfFile = Args.getLastArgValue(OPT_split_dwarf_file);
Opts.SplitDwarfInlining = !Args.hasArg(OPT_fno_split_dwarf_inlining);
+ Opts.SingleFileSplitDwarf = Args.hasArg(OPT_single_file_split_dwarf);
+
Opts.DebugTypeExtRefs = Args.hasArg(OPT_dwarf_ext_refs);
Opts.DebugExplicitImport = Args.hasArg(OPT_dwarf_explicit_import);
Opts.DebugFwdTemplateParams = Args.hasArg(OPT_debug_forward_template_params);
Index: lib/Driver/ToolChains/MinGW.cpp
===
--- lib/Driver/ToolChains/MinGW.cpp
+++ lib/Driver/ToolChains/MinGW.cpp
@@ -52,7 +52,7 @@
if (Args.hasArg(options::OPT_gsplit_dwarf))
SplitDebugInfo(getToolChain(), C, *this, JA, Args, Output,
- SplitDebugName(Args, Inputs[0]));
+ SplitDebugName(Args, Inputs[0], Output));
}
void tools::MinGW::Linker::AddLibGCC(const ArgList ,
Index:
