| Message ID | 20200513155029.br47ccmg2wjhmzu6@google.com |
|---|---|
| State | New |
| Headers | show |
| Series | Don't make -gsplit-dwarf imply -g | expand |
On Wed, May 13, 2020 at 5:50 PM Fangrui Song <maskray@google.com> wrote: > > On 2020-05-13, Eric Botcazou wrote: > >> Did I mention I dislike -fsplit-dwarf? ;) > > > >Seconded, this will be confusing for almost all users. Since the option only > >affects debug info generation, it should be prefixed with 'g' in any case. > > Updating the semantics of -gsplit-dwarf is actually my favorite as > well:) > > -gsplit-dwarf is not common. Many uses have separate -g. Let's change it. > > Attached the patch. OK if there are no objections over the weekend. I guess this change needs documenting in gcc-11/changes.html (which probably does not exist yet, will take care of that). Thanks, Richard. > > (I also wish -gdwarf-5 did not imply -g but the ship may have shipped.)
On Thu, May 14, 2020 at 12:16 AM Richard Biener <richard.guenther@gmail.com> wrote: > > On Wed, May 13, 2020 at 5:50 PM Fangrui Song <maskray@google.com> wrote: > > > > On 2020-05-13, Eric Botcazou wrote: > > >> Did I mention I dislike -fsplit-dwarf? ;) > > > > > >Seconded, this will be confusing for almost all users. Since the option only > > >affects debug info generation, it should be prefixed with 'g' in any case. > > > > Updating the semantics of -gsplit-dwarf is actually my favorite as > > well:) > > > > -gsplit-dwarf is not common. Many uses have separate -g. Let's change it. > > > > Attached the patch. > > OK if there are no objections over the weekend. I guess this change needs > documenting in gcc-11/changes.html (which probably does not exist yet, > will take care of that). > > Thanks, > Richard. > > > > > (I also wish -gdwarf-5 did not imply -g but the ship may have shipped.) Richard, are you still going to make this change? (If you do it, I'll happy to ask folks to move forward with the clang patch https://reviews.llvm.org/D80391 ) I've added a note from the original implementer (Cary Coutant) here: https://gcc.gnu.org/pipermail/gcc/2020-July/233074.html On the clang side, I don't think anyone has expressed that they would be upset by a behavior change. Several folks have expressed that the semantics are complex, though, e.g. https://github.com/ccache/ccache/issues/393
On Wed, Jul 29, 2020 at 7:24 AM Fāng-ruì Sòng <maskray@google.com> wrote: > > On Thu, May 14, 2020 at 12:16 AM Richard Biener > <richard.guenther@gmail.com> wrote: > > > > On Wed, May 13, 2020 at 5:50 PM Fangrui Song <maskray@google.com> wrote: > > > > > > On 2020-05-13, Eric Botcazou wrote: > > > >> Did I mention I dislike -fsplit-dwarf? ;) > > > > > > > >Seconded, this will be confusing for almost all users. Since the option only > > > >affects debug info generation, it should be prefixed with 'g' in any case. > > > > > > Updating the semantics of -gsplit-dwarf is actually my favorite as > > > well:) > > > > > > -gsplit-dwarf is not common. Many uses have separate -g. Let's change it. > > > > > > Attached the patch. > > > > OK if there are no objections over the weekend. I guess this change needs > > documenting in gcc-11/changes.html (which probably does not exist yet, > > will take care of that). > > > > Thanks, > > Richard. > > > > > > > > (I also wish -gdwarf-5 did not imply -g but the ship may have shipped.) > > Richard, are you still going to make this change? Sorry - I thought you'd commit the patch. I've now done that and will amend changes.html. Richard. > (If you do it, I'll happy to ask folks to move forward with the clang > patch https://reviews.llvm.org/D80391 ) > > I've added a note from the original implementer (Cary Coutant) here: > https://gcc.gnu.org/pipermail/gcc/2020-July/233074.html > > On the clang side, I don't think anyone has expressed that they would > be upset by a behavior change. > Several folks have expressed that the semantics are complex, though, > e.g. https://github.com/ccache/ccache/issues/393
On Tue, Jul 28, 2020, 10:24 PM Fāng-ruì Sòng <maskray@google.com> wrote: > On Thu, May 14, 2020 at 12:16 AM Richard Biener > <richard.guenther@gmail.com> wrote: > > > > On Wed, May 13, 2020 at 5:50 PM Fangrui Song <maskray@google.com> wrote: > > > > > > On 2020-05-13, Eric Botcazou wrote: > > > >> Did I mention I dislike -fsplit-dwarf? ;) > > > > > > > >Seconded, this will be confusing for almost all users. Since the > option only > > > >affects debug info generation, it should be prefixed with 'g' in any > case. > > > > > > Updating the semantics of -gsplit-dwarf is actually my favorite as > > > well:) > > > > > > -gsplit-dwarf is not common. Many uses have separate -g. Let's change > it. > > > > > > Attached the patch. > > > > OK if there are no objections over the weekend. I guess this change > needs > > documenting in gcc-11/changes.html (which probably does not exist yet, > > will take care of that). > > > > Thanks, > > Richard. > > > > > > > > (I also wish -gdwarf-5 did not imply -g but the ship may have shipped.) > > Richard, are you still going to make this change? > (If you do it, I'll happy to ask folks to move forward with the clang > patch https://reviews.llvm.org/D80391 ) > > I've added a note from the original implementer (Cary Coutant) here: > https://gcc.gnu.org/pipermail/gcc/2020-July/233074.html > > On the clang side, I don't think anyone has expressed that they would > be upset by a behavior change. > I think I've repeatedly expressed this. My concerns are both the break in backwards compatibility and the general direction of -g flags that don't enable debug info emission which at least myself and a couple of other long time dwarf contributors (Eric Christopher and Cary Contant) have been surprised by/not the semantics that many debug info flags have. Several folks have expressed that the semantics are complex, though, > e.g. https://github.com/ccache/ccache/issues/393 >
From d389afcaf66ae9f0549ec91437a7bcb1e3b0d7d7 Mon Sep 17 00:00:00 2001 From: Fangrui Song <maskray@google.com> Date: Wed, 13 May 2020 08:27:29 -0700 Subject: [PATCH] Don't make -gsplit-dwarf imply -g -gsplit-dwarf introduces order dependency: it overrides previous -g0 and -g1. Don't imply -g so that it can be plugged into a build without worrying that unnecessary debugging information may be generated. 2020-05-13 Fangrui Song <maskray@google.com> PR debug/95096 * common.opt: Don't make -gsplit-dwarf imply -g. * doc/invoke.texi: Update documentation. --- gcc/doc/invoke.texi | 10 +++++----- gcc/opts.c | 5 ----- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 850aeac033d..12b65f0f604 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -8796,11 +8796,11 @@ except when selective scheduling is enabled. @item -gsplit-dwarf @opindex gsplit-dwarf -Separate as much DWARF debugging information as possible into a -separate output file with the extension @file{.dwo}. This option allows -the build system to avoid linking files with debug information. To -be useful, this option requires a debugger capable of reading @file{.dwo} -files. +If DWARF debugging information is enabled, separate as much debugging +information as possible into a separate output file with the extension +@file{.dwo}. This option allows the build system to avoid linking files with +debug information. To be useful, this option requires a debugger capable of +reading @file{.dwo} files. @item -gdescribe-dies @opindex gdescribe-dies diff --git a/gcc/opts.c b/gcc/opts.c index ec3ca0720f9..b45f22d9634 100644 --- a/gcc/opts.c +++ b/gcc/opts.c @@ -2723,11 +2723,6 @@ common_handle_option (struct gcc_options *opts, set_debug_level (DWARF2_DEBUG, false, "", opts, opts_set, loc); break; - case OPT_gsplit_dwarf: - set_debug_level (NO_DEBUG, DEFAULT_GDB_EXTENSIONS, "", opts, opts_set, - loc); - break; - case OPT_ggdb: set_debug_level (NO_DEBUG, 2, arg, opts, opts_set, loc); break; -- 2.26.2.645.ge9eca65c58-goog