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

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

      reply	other threads:[~2017-12-04 16:49 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
2017-12-04 16:49   ` Jim Wilson [this message]

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=CAFyWVaaqQOe+B6XXT5rpF6im82vLjR5ztvWCbzF3jh9+Zr04iA@mail.gmail.com \
    --to=jimw@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.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).