[cfe-dev] -gsplit-dwarf implies -g
Fangrui Song via cfe-dev
cfe-dev at lists.llvm.org
Thu Jul 9 11:33:58 PDT 2020
On 2020-07-09, David Blaikie wrote:
>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
Yes. Richard Biener (a global reviewer according to gcc/MAINTAINERS) is
fine with dropping implied -g2 from -gsplit-dwarf.
>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).
I haven't discussed the mixed status quo of -f* and -g*.
It may be worth a discussion as well: whether we should set up a rule
for future debugging related options.
>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
Cary Coutant:
In retrospect, I regret not naming the option -fsplit-dwarf, which
clearly would not have implied -g, and would have fit in with a few
other dwarf-related -f options. (I don't know whether Richard's
objection to it is because there is already -gsplit-dwarf, or if he
would have objected to it as an alternative-universe spelling.)
At the time, I thought it was fairly common for all/most -g options
(except -g0) to imply -g. Perhaps that wasn't true then or is no longer
true now. If the rest of the community is OK with changing -gsplit-dwarf
to not imply -g, and no one has said it would cause them any hardship,
I'm OK with your proposed change.
I did design it so that you could get the equivalent by simply writing
"-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
environment variable), so that a subsequent -g would not only turn on
debug but would also enable split-dwarf. We used that fairly regularly
at Google.
Regarding how the build system can discover whether or not split dwarf
is in effect, without parsing all the options presented to gcc, and
without looking for the side effects (the .dwo files), we dodged that
in the Google build system by having a higher-level build flag,
--fission, which would tell the build system to pass -gsplit-dwarf to
gcc AND look for the .dwo files produced on the side. We simply
disallowed having the user pass -gsplit-dwarf directly to the
compiler.
Feel free to share this.
>
>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