<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-gsplit-dwarf takes part in the computation of amount of debugging information<br>
(clang::codegenoptions::DebugInfoKind).<br>
<br>
// <a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Clang.cpp#L3700" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Clang.cpp#L3700</a><br>
   if (const Arg *A =<br>
           Args.getLastArg(options::OPT_g_Group, options::OPT_gsplit_dwarf,<br>
                           options::OPT_gsplit_dwarf_EQ)) {<br>
     DebugInfoKind = codegenoptions::LimitedDebugInfo;<br>
<br>
     // If the last option explicitly specified a debug-info level, use it.<br>
     if (checkDebugInfoOption(A, Args, D, TC) &&<br>
         A->getOption().matches(options::OPT_gN_Group)) {<br>
       DebugInfoKind = DebugLevelToInfoKind(*A);<br>
       // For -g0 or -gline-tables-only, drop -gsplit-dwarf. This gets a bit more<br>
       // complicated if you've disabled inline info in the skeleton CUs<br>
       // (SplitDWARFInlining) - then there's value in composing split-dwarf and<br>
       // line-tables-only, so let those compose naturally in that case.<br>
       if (DebugInfoKind == codegenoptions::NoDebugInfo ||<br>
           DebugInfoKind == codegenoptions::DebugDirectivesOnly ||<br>
           (DebugInfoKind == codegenoptions::DebugLineTablesOnly &&<br>
            SplitDWARFInlining))<br>
         DwarfFission = DwarfFissionKind::None;<br>
     }<br>
   }<br>
<br>
This order dependency with other g_Group options (-g0, -g1, -g2, -ggdb3, -gdwarf-5, etc)<br>
makes it somewhat inconvenient to use in a build system:<br>
<br>
* -g0 -gsplit-dwarf -> level 2<br>
   -gsplit-dwarf "upgrades" the amount of debugging information despite the previous intention (-g0) to drop debugging information<br>
* -g1 -gsplit-dwarf -> level 2<br>
   -gsplit-dwarf "upgrades" the amount of debugging information.<br>
<br>
I guess using "-g0 -gsplit-dwarf" as a whole might be able to get rid of some<br>
order dependency in clang but it will not work greatly in gcc which has another<br>
level: -g3.<br>
<br>
What do people think we should do to make -gsplit-dwarf less confusing?<br>
<br>
Add another -f flag (-fsplit-dwarf? -fdebug-*?)<br>
Update -gsplit-dwarf to not imply -g? (If we coordinate well with GCC people, I think this is still doable<br>
<a href="https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545646.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545646.html</a> )<br></blockquote><div><br>I tend to disagree with this - I think it'd be pretty tricky for build systems to use something like -fsplit-dwarf (ie: "has no effect unless some other -gN flag is used, and then it means that debug info goes in a different file") - because then the "will here be another file" becomes unknown to the build system, so a distributed build system wouldn't know whether there's a .dwo file it needs to copy around, merge into a .dwp, etc. I guess that could be addressed by having -fsplit-dwarf be an error if no debug info is enabled, or emit an empty .dwo file if -fsplit-dwarf is specified but no -gN flag is used. </div><div><br></div><div>It also seems a bit problematic to change the semantics of this flag now that it's been out there and people are using it. (though, to be fair, it's /probably/ just Google that's using it for the most part - at least the vague impression I get - but that said, I doubt changing the semantics here would lead to a change in Google's internal build system, again, because of existing usage)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is a whole group (g_flags_Group) of -g options which do not takes part in the computation of amount of debugging information<br>
(-gz, -grecord-command-line, -gstrict-dwarf, etc).<br></blockquote><div><br></div><div>Equally there are flags that affect debug info generation that aren't -g: -fdebug-types-section, for instance. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Honestly I would hope -gdwarf-5 did not affect DebugInfoKind (we would not need -fdebug-default-version=5)<br>
but the -gdwarf- ship has sailed.<br></blockquote><div><br>Any particular reason the -gdwarf-N ship has sailed beyond the point of changability moreso than -gsplit-dwarf?<br><br>- Dave</div></div></div>