public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
Cc: Mark Wielaard <mark@klomp.org>,  Eli Zaretskii <eliz@gnu.org>,
	tom@tromey.com
Subject: Re: [RFC] Deprecate stabs
Date: Fri, 10 Feb 2023 19:26:12 -0700	[thread overview]
Message-ID: <87a61lgcor.fsf@tromey.com> (raw)
In-Reply-To: <83y1pxmi7b.fsf@gnu.org> (Eli Zaretskii via Gdb-patches's message of "Fri, 20 Jan 2023 15:47:04 +0200")

>> stabs support was deprecated in GCC 12 [1] and has been removed in GCC
>> 13 [2], which is in pre-release state (stage 4) now. So the above plan
>> actually trails GCC by two releases. So I would actually recommend
>> adding a deprecation notice in GDB 13 and removal in GDB 14.

Eli> I see no reason to rush with removal of features.  Someone could still
Eli> be using them.  And users don't necessarily upgrade to the latest
Eli> version of GCC as soon as it is released, they could go on using an
Eli> older version for some years.

Eli> We should be friendlier to our users than MS and Google.

I agree with all these principles, but they don't really apply to stabs.

Stabs have been obsolete since before I began working on gdb.  When I
worked at Red Hat, we'd occasionally stumble over some program using
them -- and this always turned out to be by mistake.  That is, just user
ignorance, perhaps they read some web page from 1988 saying use -gstabs.

Similarly, when replying to bugs in bugzilla, more than once some crash
has turned out to be due to stabs being in use.  I just tell those
people sorry, nobody works on stabs or even really understands the stabs
format or reader any more.  s/-gstabs/-g/ usually fixes the problems.

If there is some person who really does use stabs, I don't think they'll
really be harmed by having to use GDB 13.

Finally, deprecation serves the purpose of announcing our intent.  Maybe
someone will step up to maintain this code, in which case we can keep
it.  In this scenario, I would be ok with treating it like the
un-maintained *-nat code -- we'll try to keep it building but testing
and fixing it is up to the maintainer.

If/when this goes in, I'll send a deprecation announcement to the gdb
list, in case there is some such person who can be flushed out of the
cobwebs.

thanks,
Tom

  reply	other threads:[~2023-02-11  2:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 17:41 Tom Tromey
2023-01-19 18:00 ` Eli Zaretskii
2023-01-20 12:48   ` Mark Wielaard
2023-01-20 13:47     ` Eli Zaretskii
2023-02-11  2:26       ` Tom Tromey [this message]
2023-02-11  8:29         ` Eli Zaretskii
2023-02-14 16:36           ` Simon Marchi
2023-02-12 12:53         ` Mark Wielaard
2023-07-06 17:44 ` Pedro Alves
2023-08-30 17:48   ` Tom Tromey
2023-08-30 17:58     ` Eli Zaretskii
2023-08-30 19:15     ` Kevin Buettner
2023-08-30 20:47     ` John Baldwin

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=87a61lgcor.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=mark@klomp.org \
    /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).