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

Fangrui Song via cfe-dev cfe-dev at lists.llvm.org
Wed Jun 10 09:39:12 PDT 2020 

On 2020-06-01, David Blaikie wrote:
> 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)

GCC does not mind changing the semantics of -gsplit-dwarf, but they want
to avoid new -f options
(see https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545646.html and its replies)
(On their side, "-gsplit-dwarf is largely unmaintained")

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

I asked but got no response:/

On 2020-06-02, David Blaikie wrote:
>On Tue, Jun 2, 2020 at 3:13 AM Lubos Lunak <l.lunak at centrum.cz> wrote:
>>
>> On Tuesday 02 of June 2020, David Blaikie via cfe-dev wrote:
>> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <maskray at google.com> wrote:
>> > > 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.
>>
>>  I don't know specifically about distcc, but Clang's -gsplit-dwarf has been a
>> hassle for both icecc and ccache. They both know about -gsplit-dwarf and .dwo
>> files, but in the end the simplest solution turned out to be not to rely on
>> presence of -gsplit-dwarf and instead remove any stale .dwo and after
>> compilation check if .dwo exists (see e.g.
>> https://github.com/ccache/ccache/issues/393).
>
>Ah, interesting to know/understand - thanks for the details!

More information about the cfe-dev mailing list