[RFA] Deprecate stabs if dwarf2 support available.

This is based on an idea from Richard Biener that was mentioned here
    https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02376.html

If we are interested in doing this, it would be accompanied by documentation
changes to state that stabs is now deprecated in favor of dwarf2, release
notes to announce the change, and a configure patch to deprecate --with-stabs.
We will also need a patch for the debug torture testing in the testsuite to
check for the new error.  There may also be other things we need that I haven't
noticed yet.

I tried testing a number of targets that use stabs to see what would happen
with this change.

There are 3 targets that default to stabs, and -g continues to emit stabs
with this patch: m68k-openbsd, pdp11, vax-openbsd.

There are 3 targets that default to stabs, and -g now gives an error: avr-elf,
i386-lynxos, powerpc-lynxos.  avr includes elfos.h which defines
DWARF2_DEBUGGING_INFO.  We can temporarily fix avr by adding a #undef for that.
I think i386-lynxos and powerpc-lynxos should switch to dwarf2, as both i386
and powerpc support dwarf2.  But if necessary, we can temporarily fix them
with the same change.

There are 2 targets that emit dwarf2 by default, but emit stabs when
the --with-stabs configure option is used: mn10300-elf, v850-elf.  They
continue to work fine by default, but -g fails if you use --with-stabs.  The
solution here is to add a configure patch to give an error when --with-stabs
is used.

And of course for the vast majority of targets, which support dwarf2 by
default, -g works fine, and -gstabs now gives an error.

There is also a configuration for cygwin, with an old non-dwarf assembler,
that defaults to stabs, but that probably doesn't even build anymore.  And
there is also a configuration for pre-darwin9 that defaults to stabs, but that
may not be buildable anymore either.

This doesn't break AIX/XCOFF, as we aren't trying to remove any code at this
time.

It is possible that there might also be other targets affected by the change
that I haven't noticed yet.  I tried searching for all targets using stabs,
but might have missed a few.

Jim

	gcc/
	* toplev.c (process_options): If DWARF2_DEBUGGING_INFO defined, and
	write_symbols set to DBX_DEBUG, give an error.
---
 gcc/toplev.c | 6 ++++++
 1 file changed, 6 insertions(+)

On Sun, Dec 3, 2017 at 5:17 AM, Jim Wilson <jimw@sifive.com> wrote:
> This is based on an idea from Richard Biener that was mentioned here
>     https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02376.html
>
> If we are interested in doing this, it would be accompanied by documentation
> changes to state that stabs is now deprecated in favor of dwarf2, release
> notes to announce the change, and a configure patch to deprecate --with-stabs.
> We will also need a patch for the debug torture testing in the testsuite to
> check for the new error.  There may also be other things we need that I haven't
> noticed yet.

Note that "deprecation" doesn't match up with giving an error when using.
We should warn (or maybe just document deprecation) instead.

IMHO unless we can get rid of stabs support it isn't worth being this drastic.

Maybe we can add a DWARF2_ONLY_DEBUGGING_INFO or
NO_DBX_DEBUGGING_INFO macro so targets can decide they do not
want to support -gstabs and reject it this way?  I'm not sure if
#undefing DBX_DEBUGGING_INFO for those targets would be enough to
achieve this?  It seems clearly not.  Thus sth like

Index: gcc/opts.c
===================================================================
--- gcc/opts.c  (revision 255375)
+++ gcc/opts.c  (working copy)
@@ -2383,6 +2383,10 @@ common_handle_option (struct gcc_options

     case OPT_gstabs:
     case OPT_gstabs_:
+#ifndef DBX_DEBUGGING_INFO
+      warning ("-gstabs is deprecated on this target");
+
+#endif
       set_debug_level (DBX_DEBUG, code == OPT_gstabs_, arg, opts, opts_set,
                       loc);
       break;

and/or ignore stabs and use -gdwarf -g1 when -gstabs is specified?

Seems x86_64-linux includes dbxelf.h via config.gcc so the above has
no effect there for example.

OTOH removing that would probably completely remove stabs support.

So unless we want to remove any support for GCC 8 I'd suggest to document
the deprecation in gcc-8/changes.html and emit a deprecation warning from
the --with-stabs configure option.  Note that deprecating stabs means
deprecating
those targets (or just debugging on those?) that only support stabs.

> I tried testing a number of targets that use stabs to see what would happen
> with this change.
>
> There are 3 targets that default to stabs, and -g continues to emit stabs
> with this patch: m68k-openbsd, pdp11, vax-openbsd.
>
> There are 3 targets that default to stabs, and -g now gives an error: avr-elf,
> i386-lynxos, powerpc-lynxos.  avr includes elfos.h which defines
> DWARF2_DEBUGGING_INFO.  We can temporarily fix avr by adding a #undef for that.
> I think i386-lynxos and powerpc-lynxos should switch to dwarf2, as both i386
> and powerpc support dwarf2.  But if necessary, we can temporarily fix them
> with the same change.
>
> There are 2 targets that emit dwarf2 by default, but emit stabs when
> the --with-stabs configure option is used: mn10300-elf, v850-elf.  They
> continue to work fine by default, but -g fails if you use --with-stabs.  The
> solution here is to add a configure patch to give an error when --with-stabs
> is used.
>
> And of course for the vast majority of targets, which support dwarf2 by
> default, -g works fine, and -gstabs now gives an error.
>
> There is also a configuration for cygwin, with an old non-dwarf assembler,
> that defaults to stabs, but that probably doesn't even build anymore.  And
> there is also a configuration for pre-darwin9 that defaults to stabs, but that
> may not be buildable anymore either.
>
> This doesn't break AIX/XCOFF, as we aren't trying to remove any code at this
> time.
>
> It is possible that there might also be other targets affected by the change
> that I haven't noticed yet.  I tried searching for all targets using stabs,
> but might have missed a few.
>
> Jim
>
>         gcc/
>         * toplev.c (process_options): If DWARF2_DEBUGGING_INFO defined, and
>         write_symbols set to DBX_DEBUG, give an error.
> ---
>  gcc/toplev.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 2f154960a17..f5cee35234e 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -1482,6 +1482,12 @@ process_options (void)
>               "target system does not support the %qs debug format",
>               debug_type_names[write_symbols]);
>
> +#if defined(DWARF2_DEBUGGING_INFO)
> +  if (write_symbols == DBX_DEBUG)
> +    error_at (UNKNOWN_LOCATION,
> +             "DBX/stabs debugging info format is deprecated, use DWARF2 instead.");
> +#endif
> +
>    /* We know which debug output will be used so we can set flag_var_tracking
>       and flag_var_tracking_uninit if the user has not specified them.  */
>    if (debug_info_level < DINFO_LEVEL_NORMAL
> --
> 2.14.1
>

On Mon, Dec 4, 2017 at 2:38 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> Note that "deprecation" doesn't match up with giving an error when using.
> We should warn (or maybe just document deprecation) instead.

OK.  I can warn instead.  That makes a lot of things simpler for
gcc-8.  Nothing will be broken by the change, except for the debug
torture support in the gcc testsuite, which is easy enough to fix.

> Maybe we can add a DWARF2_ONLY_DEBUGGING_INFO or
> NO_DBX_DEBUGGING_INFO macro so targets can decide they do not
> want to support -gstabs and reject it this way?  I'm not sure if
> #undefing DBX_DEBUGGING_INFO for those targets would be enough to
> achieve this?  It seems clearly not.  Thus sth like

I think we have too many *_DEBUGGING_INFO macros already.  And some of
them are undocumented and/or incorrectly documented.  So I'd rather
not add more.  DWARF2_LINENO_DEBUGGING_INFO is undocumented.
XCOFF_DEBUGGING_INFO is incorrectly documented.  The docs say it emits
a stabs variant, but it is used in both dbxout.c and dwarf2out.c, so
it is also emitting a dwarf2 variant.

> +#ifndef DBX_DEBUGGING_INFO
> +      warning ("-gstabs is deprecated on this target");
> +
> +#endif

It is already the case that you can't emit stabs if DBX_DEBUGGING_INFO
is not defined.  So this patch would do nothing useful.

rohan:2017$ ./xgcc -B./ -gstabs tmp.c
cc1: error: target system does not support the ‘stabs’ debug format
rohan:2018$

> and/or ignore stabs and use -gdwarf -g1 when -gstabs is specified?

Except that we can't emit dwarf-2 unless DWARF2_DEBUGGING_INFO is
defined.  So that takes us back to my patch which checks for
DWARF2_DEBUGGING_INFO.  It just needs to emit a warning instead of an
error, and then force a switch to dwarf2.

That leaves open the question of what to do about targets that only
support stabs.  We could do nothing for now and continue to emit
stabs.  We could call inform() to emit the deprecation message, to
avoid breaking -Werror, and continue to emit stabs.  I think the
latter is more useful, so I will try that.

> So unless we want to remove any support for GCC 8 I'd suggest to document
> the deprecation in gcc-8/changes.html and emit a deprecation warning from
> the --with-stabs configure option.  Note that deprecating stabs means
> deprecating
> those targets (or just debugging on those?) that only support stabs.

No, I don't want to remove stabs support at this time.  I just want to
start nudging people in the right direction, to switch to dwarf2.  I
think avr is the only actively maintained target that depends on
stabs, and we can ask them to add dwarf support.  For the other
targets, we can just drop debugging support if people are still
interested in the target, or drop the target if no one is still
interested in it.

Jim