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

[David Blaikie via cfe-dev]

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.

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)


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


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200514/42bde3ee/attachment.html>