[cfe-dev] -gsplit-dwarf implies -g
David Blaikie via cfe-dev
cfe-dev at lists.llvm.org
Thu Jul 9 11:12:24 PDT 2020
Ray - perhaps we could continue the conversation here, rather than
splitting it back over to D80391 ?
Could you point me to the GCC conversation around -g V -f flags? is it
these two emails:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545646.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545657.html ? Was
there any further discussion about other -f flags that only affect
debug info output (like -fdebug-types-section and the
recently-implemented-in-clang-with-compatibility-with-gcc
-fno-eliminate-unused-debug-symbols). The fact that Cary (in the email
you quoted in D80391 - might be handy to include that detail here in
this thread) had a similar understanding to me about -g mostly/often
implying debug info generation leaves me a bit more confident that
maybe more discussion around -f V -g is merited.
- Dave
On Wed, Jun 10, 2020 at 9:39 AM Fangrui Song <maskray at google.com> wrote:
>
> 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