[cfe-dev] -gsplit-dwarf implies -g

[David Blaikie via cfe-dev]

On Wed, May 20, 2020 at 12:28 PM Fangrui Song <maskray at google.com> wrote:
>
> On 2020-05-14, David Blaikie wrote:
> >On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <
> >cfe-dev at lists.llvm.org> wrote:
> >
> >> -gsplit-dwarf takes part in the computation of amount of debugging
> >> information
> >> (clang::codegenoptions::DebugInfoKind).
> >>
> >> //
> >> https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Clang.cpp#L3700
> >>    if (const Arg *A =
> >>            Args.getLastArg(options::OPT_g_Group, options::OPT_gsplit_dwarf,
> >>                            options::OPT_gsplit_dwarf_EQ)) {
> >>      DebugInfoKind = codegenoptions::LimitedDebugInfo;
> >>
> >>      // If the last option explicitly specified a debug-info level, use it.
> >>      if (checkDebugInfoOption(A, Args, D, TC) &&
> >>          A->getOption().matches(options::OPT_gN_Group)) {
> >>        DebugInfoKind = DebugLevelToInfoKind(*A);
> >>        // For -g0 or -gline-tables-only, drop -gsplit-dwarf. This gets a
> >> bit more
> >>        // complicated if you've disabled inline info in the skeleton CUs
> >>        // (SplitDWARFInlining) - then there's value in composing
> >> split-dwarf and
> >>        // line-tables-only, so let those compose naturally in that case.
> >>        if (DebugInfoKind == codegenoptions::NoDebugInfo ||
> >>            DebugInfoKind == codegenoptions::DebugDirectivesOnly ||
> >>            (DebugInfoKind == codegenoptions::DebugLineTablesOnly &&
> >>             SplitDWARFInlining))
> >>          DwarfFission = DwarfFissionKind::None;
> >>      }
> >>    }
> >>
> >> This order dependency with other g_Group options (-g0, -g1, -g2, -ggdb3,
> >> -gdwarf-5, etc)
> >> makes it somewhat inconvenient to use in a build system:
> >>
> >> * -g0 -gsplit-dwarf -> level 2
> >>    -gsplit-dwarf "upgrades" the amount of debugging information despite
> >> the previous intention (-g0) to drop debugging information
> >> * -g1 -gsplit-dwarf -> level 2
> >>    -gsplit-dwarf "upgrades" the amount of debugging information.
> >>
> >> I guess using "-g0 -gsplit-dwarf" as a whole might be able to get rid of
> >> some
> >> order dependency in clang but it will not work greatly in gcc which has
> >> another
> >> level: -g3.
> >>
> >> What do people think we should do to make -gsplit-dwarf less confusing?
> >>
> >> Add another -f flag (-fsplit-dwarf? -fdebug-*?)
> >> Update -gsplit-dwarf to not imply -g? (If we coordinate well with GCC
> >> people, I think this is still doable
> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545646.html )
> >>
> >
> >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.
>
> Thanks for bring up the .dwo + build system (Bazel) issue.
> Can Bazel be taught to treat the output .dwo optionally?

I think we already have a workaround in the compiler-running script
that essentially produces an empty .dwo file in case the compiler
doesn't produce one (eg, if you use -g0 to compile some files but not
others).

> I think the build system argument might be weak because
> the user can specify --copt=-g1 --copt=-fsplit-dwarf-inlining or
> --copt=-gline-directives-only to suppress .dwo
>
> -gsplit-dwarf -g1 -fsplit-dwarf-inlining => no dwo
> -gsplit-dwarf -gline-directives-only => no dwo
>
> If the build system is structured the way that it will fail when no dwo
> is retained... It might be cumbersome.

Yep - I suppose it's perhaps more instructive to look at it in the
other direction - /adding/ -gsplit-dwarf to a build that doesn't
otherwise use it/know about (distcc/etc) would likely break, I imagine
(such a system would only know to copy the .o files around the
distributed builders, and wouldn't know to bring back the .dwo files
to the users machine). Though there's probably other flags that have
that property too - so it's not an iron clad argument, to be sure.

> >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)
>
> I hope so:) For Google's use cases, before we can fix the .dwo problem,
> we can replace -gsplit-dwarf with -gsplit-dwarf -g to remain the current
> semantics.
>
> Old -gsplit-dwarf = proposed -gsplit-dwarf -g
>
> I proposed because there are confused internal users confused and I hope
> can still alter -gsplit-dwarf to make it easier to understand in the
> future.

I've seen a couple of people mention this, but I'm not sure it rises
to the level of problem that justifies changing the semantics of an
existing flag - and I'm marginal on whether it's worth adding a new
flag.

I do like orthogonal features, though - and, yes, the composability of
some "use split DWARF if debug info is being emitted" flag is a nice
thing.

>
> >> There is a whole group (g_flags_Group) of -g options which do not takes
> >> part in the computation of amount of debugging information
> >> (-gz, -grecord-command-line, -gstrict-dwarf, etc).
> >>
> >
> >Equally there are flags that affect debug info generation that aren't -g:
> >-fdebug-types-section, for instance.
>
> There are. Unfortunately the options don't have simple consistent names
> now
> https://sourceware.org/pipermail/gcc-patches/2011-March/309163.html
>
> >>
> >> Honestly I would hope -gdwarf-5 did not affect DebugInfoKind (we would not
> >> need -fdebug-default-version=5)
> >> but the -gdwarf- ship has sailed.
> >>
> >
> >Any particular reason the -gdwarf-N ship has sailed beyond the point of
> >changability moreso than -gsplit-dwarf?
> >
> >- Dave
>
> I just remember that you had an argument for -fdebug-default-version=
> If -gdwarf- did not add -g implicitly, we would not need -fdebug-default-version=

Yeah, my argument would be pretty similar here - breaking
compatibility of the command line interface seems worth trying to
avoid. (& using "-f" flags to modify debug info output behavior, while
not itself asknig for debug info, seems pretty reasonable/common
already)

Not entirely sure what the GCC attitude about debug info flags is -
whether the -f* flags were considered a historical mistake or what,
but I guess likely we'll end up wanting to follow along with their
values there if the couple of comments on the thread over there are
representative - not sure how to evaluate that. (this change aside -
if they're going to add more -g flags for other situations that change
debug info generation behavior without actually enabling debug info
generation themselves, then we'll likely want to follow, as much as I
find it awkward/odd)

Not sure if/might be worth pulling in Cary Coutant over there or over
here... really not sure where the best discussion venue is to try to
hash it all out.