[PATCH] Add -fsplit-dwarf

[PATCH] Add -fsplit-dwarf

[Fangrui Song]

-fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging
information by itself. This makes it easier to be plugged into a build
system without worrying that unnecessary debugging information may be
generated.

2020-05-12  Fangrui Song  <maskray@google.com>

	PR debug/95096
	* common.opt: Add -fsplit-dwarf.
	* doc/invoke.texi: Document it.
---
 gcc/common.opt      | 4 ++++
 gcc/doc/invoke.texi | 8 ++++++++
 2 files changed, 12 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..07aa9f28002 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2515,6 +2515,10 @@ fsingle-precision-constant
 Common Report Var(flag_single_precision_constant) Optimization
 Convert floating point constants to single precision constants.
 
+fsplit-dwarf
+Common Driver Var(dwarf_split_debug_info) Init(0)
+If debug information is enabled, generate debug information in separate .dwo files.
+
 fsplit-ivs-in-unroller
 Common Report Var(flag_split_ivs_in_unroller) Init(1) Optimization
 Split lifetimes of induction variables when loops are unrolled.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 850aeac033d..6590e60f5b3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -448,6 +448,7 @@ Objective-C and Objective-C++ Dialects}.
 -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
 -fno-eliminate-unused-debug-symbols  -femit-class-debug-always @gol
 -fno-merge-debug-strings  -fno-dwarf2-cfi-asm @gol
+-fsplit-dwarf @gol
 -fvar-tracking  -fvar-tracking-assignments}
 
 @item Optimization Options
@@ -8771,6 +8772,13 @@ also be used to change an absolute path to a relative path by using
 are location independent, but may require an extra command to tell GDB
 where to find the source files. See also @option{-ffile-prefix-map}.
 
+@item -fsplit-dwarf
+@opindex fsplit-dwarf
+If DWARF debugging information is enabled, separate as much debugging
+information as possible into a separate output file with the extension
+@file{.dwo}. This is similar to @option{-gsplit-dwarf}, but this option
+does not enable debugging information by itself.
+
 @item -fvar-tracking
 @opindex fvar-tracking
 Run variable tracking pass.  It computes where variables are stored at each
-- 
2.26.2.645.ge9eca65c58-goog

Re: [PATCH] Add -fsplit-dwarf

[Richard Biener]

On Wed, May 13, 2020 at 1:40 AM Fangrui Song via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> -fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging
> information by itself. This makes it easier to be plugged into a build
> system without worrying that unnecessary debugging information may be
> generated.

Hmm.  I think having both -fsplit-dwarf and -gsplit-dwarf is confusing.  Doesn't
feeding -g0 -gsplit-dwarf into the build system work with a later -g then
enabling debug info generation?

Having said that my preference would be (in the following order):

 1) make -gsplit-dwarf not imply -g
 2) add -gsplit-dwarf0 implying -g0 (and maybe accept -gsplit-dwarf[012])

for 1) the ship may have sailed.  For 2) it might be confused
with -gdwarf2 so maybe it should be -g0split-dwarf.  Eh.

I still like 1) most.

Oh, and -gsplit-dwarf is largely unmaintained.

Did I mention I dislike -fsplit-dwarf? ;)

Richard.

> 2020-05-12  Fangrui Song  <maskray@google.com>
>
>         PR debug/95096
>         * common.opt: Add -fsplit-dwarf.
>         * doc/invoke.texi: Document it.
> ---
>  gcc/common.opt      | 4 ++++
>  gcc/doc/invoke.texi | 8 ++++++++
>  2 files changed, 12 insertions(+)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 4464049fc1f..07aa9f28002 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2515,6 +2515,10 @@ fsingle-precision-constant
>  Common Report Var(flag_single_precision_constant) Optimization
>  Convert floating point constants to single precision constants.
>
> +fsplit-dwarf
> +Common Driver Var(dwarf_split_debug_info) Init(0)
> +If debug information is enabled, generate debug information in separate .dwo files.
> +
>  fsplit-ivs-in-unroller
>  Common Report Var(flag_split_ivs_in_unroller) Init(1) Optimization
>  Split lifetimes of induction variables when loops are unrolled.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 850aeac033d..6590e60f5b3 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -448,6 +448,7 @@ Objective-C and Objective-C++ Dialects}.
>  -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
>  -fno-eliminate-unused-debug-symbols  -femit-class-debug-always @gol
>  -fno-merge-debug-strings  -fno-dwarf2-cfi-asm @gol
> +-fsplit-dwarf @gol
>  -fvar-tracking  -fvar-tracking-assignments}
>
>  @item Optimization Options
> @@ -8771,6 +8772,13 @@ also be used to change an absolute path to a relative path by using
>  are location independent, but may require an extra command to tell GDB
>  where to find the source files. See also @option{-ffile-prefix-map}.
>
> +@item -fsplit-dwarf
> +@opindex fsplit-dwarf
> +If DWARF debugging information is enabled, separate as much debugging
> +information as possible into a separate output file with the extension
> +@file{.dwo}. This is similar to @option{-gsplit-dwarf}, but this option
> +does not enable debugging information by itself.
> +
>  @item -fvar-tracking
>  @opindex fvar-tracking
>  Run variable tracking pass.  It computes where variables are stored at each
> --
> 2.26.2.645.ge9eca65c58-goog
>

Re: [PATCH] Add -fsplit-dwarf

[Eric Botcazou]

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

-- 
Eric Botcazou

[PATCH] Don't make -gsplit-dwarf imply -g

[Fangrui Song]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

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.


(I also wish -gdwarf-5 did not imply -g but the ship may have shipped.)

[-- Attachment #2: 0001-Don-t-make-gsplit-dwarf-imply-g.patch --]
[-- Type: text/x-diff, Size: 2155 bytes --]

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

Re: [PATCH] Don't make -gsplit-dwarf imply -g

[Richard Biener]

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

Re: [PATCH] Don't make -gsplit-dwarf imply -g

[Fāng-ruì Sòng]

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

Re: [PATCH] Don't make -gsplit-dwarf imply -g

[Richard Biener]

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

Re: [PATCH] Don't make -gsplit-dwarf imply -g

[David Blaikie]

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
>