public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Jim Wilson <jimw@sifive.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [RFA, PATCH] Deprecate stabs if dwarf2 support available.
Date: Mon, 04 Dec 2017 10:38:00 -0000	[thread overview]
Message-ID: <CAFiYyc1_9=RzG+WU67hiaVTBMfVugprNRUHDz5rRXG-L0ek45Q@mail.gmail.com> (raw)
In-Reply-To: <20171203041719.11506-1-jimw@sifive.com>

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
>

  reply	other threads:[~2017-12-04 10:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-03  4:17 Jim Wilson
2017-12-04 10:38 ` Richard Biener [this message]
2017-12-04 16:49   ` Jim Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFiYyc1_9=RzG+WU67hiaVTBMfVugprNRUHDz5rRXG-L0ek45Q@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jimw@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).