-gsplit-dwarf implies -g

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

-gsplit-dwarf implies -g

Fangrui Song 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

Fangrui Song 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

Fangrui Song 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

Fangrui Song via cfe-dev
In reply to this post by Fangrui Song 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

Fangrui Song 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