-gsplit-dwarf implies -g

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

-gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
-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 )

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

Honestly I would hope -gdwarf-5 did not affect DebugInfoKind (we would not need -fdebug-default-version=5)
but the -gdwarf- ship has sailed.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev


On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <[hidden email]> 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

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
On 2020-05-14, David Blaikie wrote:

>On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <
>[hidden email]> 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 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.

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

>> 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=
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
I don't have an opinion on this, but I note that we didn't expect the current behavior in chromium and tripped over it (https://source.chromium.org/chromium/chromium/src/+/master:build/config/compiler/BUILD.gn;l=2350?q=gsplit-dwarf%20file:%5C.gn). So that's a data point suggesting that the current behavior is confusing at least.

On Wed, May 13, 2020 at 6:32 PM Fangrui Song via cfe-dev <[hidden email]> 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 )

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

Honestly I would hope -gdwarf-5 did not affect DebugInfoKind (we would not need -fdebug-default-version=5)
but the -gdwarf- ship has sailed.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
On 2020-05-20, Nico Weber wrote:
>I don't have an opinion on this, but I note that we didn't expect the
>current behavior in chromium and tripped over it (
>https://source.chromium.org/chromium/chromium/src/+/master:build/config/compiler/BUILD.gn;l=2350?q=gsplit-dwarf%20file:%5C.gn).
>So that's a data point suggesting that the current behavior is confusing at
>least.

Thanks for the data point.
Created https://reviews.llvm.org/D80391 [Driver] Don't make -gsplit-dwarf imply -g2

>On Wed, May 13, 2020 at 6:32 PM Fangrui Song via cfe-dev <
>[hidden email]> 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 )
>>
>> 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).
>>
>> Honestly I would hope -gdwarf-5 did not affect DebugInfoKind (we would not
>> need -fdebug-default-version=5)
>> but the -gdwarf- ship has sailed.
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
In reply to this post by Vassil Vassilev via cfe-dev
On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> wrote:

>
> On 2020-05-14, David Blaikie wrote:
> >On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <
> >[hidden email]> 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.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
On Tuesday 02 of June 2020, David Blaikie via cfe-dev wrote:

> On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> 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).

--
 Lubos Lunak
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
On Tue, Jun 2, 2020 at 3:13 AM Lubos Lunak <[hidden email]> wrote:

>
> On Tuesday 02 of June 2020, David Blaikie via cfe-dev wrote:
> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> 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!
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
On 2020-06-01, David Blaikie wrote:

> On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> wrote:
> >
> > On 2020-05-14, David Blaikie wrote:
> > >On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <
> > >[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Tuesday 02 of June 2020, David Blaikie via cfe-dev wrote:
>> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> 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!
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
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 <[hidden email]> wrote:

>
> On 2020-06-01, David Blaikie wrote:
> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> wrote:
> > >
> > > On 2020-05-14, David Blaikie wrote:
> > > >On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <
> > > >[hidden email]> 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 <[hidden email]> wrote:
> >>
> >> On Tuesday 02 of June 2020, David Blaikie via cfe-dev wrote:
> >> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> 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!
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: -gsplit-dwarf implies -g

Vassil Vassilev via cfe-dev
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 <[hidden email]> wrote:
>>
>> On 2020-06-01, David Blaikie wrote:
>> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> wrote:
>> > >
>> > > On 2020-05-14, David Blaikie wrote:
>> > > >On Wed, May 13, 2020 at 3:32 PM Fangrui Song via cfe-dev <
>> > > >[hidden email]> 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 <[hidden email]> wrote:
>> >>
>> >> On Tuesday 02 of June 2020, David Blaikie via cfe-dev wrote:
>> >> > On Wed, May 20, 2020 at 12:28 PM Fangrui Song <[hidden email]> 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!
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev