[RFC] Deprecate stabs

[RFC] Deprecate stabs

[Tom Tromey]

I think it's time to deprecate stabs, and plan to remove all support
for them.  Stabs are long since obsolete and are not really maintained
in gdb.  GCC deprecated them in 12 and will remove them as well.
---
 gdb/NEWS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/NEWS b/gdb/NEWS
index c0aac212e30..317f6536bc0 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -5,6 +5,9 @@
 
 * MI version 1 has been removed.
 
+* Support for the stabs debugging format is deprecated, and it will be
+  removed in GDB 15.
+
 * GDB has initial built-in support for the Debugger Adapter Protocol.
   This support requires that GDB be built with Python scripting
   enabled.
-- 
2.39.0

Re: [RFC] Deprecate stabs

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>
> Date: Thu, 19 Jan 2023 10:41:56 -0700
> 
> I think it's time to deprecate stabs, and plan to remove all support
> for them.  Stabs are long since obsolete and are not really maintained
> in gdb.  GCC deprecated them in 12 and will remove them as well.

IMO, we should remove support for stabs _after_ GCC, not before and
not together with it.  Not sure if "GDB 15" fits that.

Re: [RFC] Deprecate stabs

[Mark Wielaard]

Hi,

On Thu, 2023-01-19 at 20:00 +0200, Eli Zaretskii wrote:
> > From: Tom Tromey <tom@tromey.com>
> > Cc: Tom Tromey <tom@tromey.com>
> > Date: Thu, 19 Jan 2023 10:41:56 -0700
> > 
> > I think it's time to deprecate stabs, and plan to remove all support
> > for them.  Stabs are long since obsolete and are not really maintained
> > in gdb.  GCC deprecated them in 12 and will remove them as well.
> 
> IMO, we should remove support for stabs _after_ GCC, not before and
> not together with it.  Not sure if "GDB 15" fits that.

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.

Cheers,

Mark

[1] https://gcc.gnu.org/gcc-12/changes.html
STABS: Support for emitting the STABS debugging format is deprecated
and will be removed in the next release. All ports now default to emit
DWARF (version 2 or later) debugging info or are obsoleted.

[2] 
https://gcc.gnu.org/gcc-13/changes.html
Support for emitting the STABS debugging format (including the -gstabs
and -gxcoff options) has been removed. (This means the dbx debugger is
no longer supported, either.)

Re: [RFC] Deprecate stabs

[Eli Zaretskii]

> From: Mark Wielaard <mark@klomp.org>
> Cc: gdb-patches@sourceware.org
> Date: Fri, 20 Jan 2023 13:48:27 +0100
> 
> On Thu, 2023-01-19 at 20:00 +0200, Eli Zaretskii wrote:
> > > From: Tom Tromey <tom@tromey.com>
> > > Cc: Tom Tromey <tom@tromey.com>
> > > Date: Thu, 19 Jan 2023 10:41:56 -0700
> > > 
> > > I think it's time to deprecate stabs, and plan to remove all support
> > > for them.  Stabs are long since obsolete and are not really maintained
> > > in gdb.  GCC deprecated them in 12 and will remove them as well.
> > 
> > IMO, we should remove support for stabs _after_ GCC, not before and
> > not together with it.  Not sure if "GDB 15" fits that.
> 
> 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.

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

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

Re: [RFC] Deprecate stabs

[Tom Tromey]

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

Re: [RFC] Deprecate stabs

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Mark Wielaard <mark@klomp.org>,  Eli Zaretskii <eliz@gnu.org>,
>   tom@tromey.com
> Date: Fri, 10 Feb 2023 19:26:12 -0700
> 
> >> 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.

You are probably thinking about using GDB on GNU/Linux.  By contrast,
on MS-Windows -gstabs was the only reasonable debug info type until
GCC learned how to produce DWARF2 in PE-COFF images.  I think GCC 3.x
on Windows couldn't emit DWARF2 debug info.  And don't get me started
on go32 (a.k.a. DJGPP), where in some cases one still has to use -gcoff.

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

And that is a perfectly valid response, IMO.  But removing the support
altogether means that it is unavailable even in those cases where it
does not cause a crash.  Which to me sounds too drastic.

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

This is based on the assumption that GDB 13 (or any other old version)
can be built on any future system without trouble.  But that is false,
because systems are upgraded and make old versions fail to build,
since no one takes care of adapting old versions to new libraries and
changes in system calls.  So the moment comes soon enough when using
an old version of GDB on a contemporary system is no longer an option.

> Finally, deprecation serves the purpose of announcing our intent.

So will the announcement of the feature being deprecated and
unmaintained.  It just lets the feature die of natural causes instead
of euthanasia.

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

That's what I think we should do: leave the code unmaintained, but not
remove it in its entirety.

Thanks.

Re: [RFC] Deprecate stabs

[Simon Marchi]

> This is based on the assumption that GDB 13 (or any other old version)
> can be built on any future system without trouble.  But that is false,
> because systems are upgraded and make old versions fail to build,
> since no one takes care of adapting old versions to new libraries and
> changes in system calls.  So the moment comes soon enough when using
> an old version of GDB on a contemporary system is no longer an option.

At this point, people who want stabs support can take care of keeping
GDB 13 building on whatever system they are using.  We're talking about
something that has been obsolete for at least 15 years, not something
that has been been obsoleted last year.

> So will the announcement of the feature being deprecated and
> unmaintained.  It just lets the feature die of natural causes instead
> of euthanasia.

What does "die of nature causes" mean?  It's not like the code will
naturally disappear if we don't delete it.

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

Agreed.

> That's what I think we should do: leave the code unmaintained, but not
> remove it in its entirety.

It still gets in the way when doing changes to the generic symbol
infrastructure.  You have to think about how to adjust stabs, you can't
just ignore it.

Simon

Re: [RFC] Deprecate stabs

[Mark Wielaard]

Hi Tom,

On Fri, Feb 10, 2023 at 07:26:12PM -0700, Tom Tromey wrote:
> 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.

I like this approach. It would be good to announce this asap, so
people who do actually use stabs and care about improving, testing and
maintaining support can step up. And if nobody does then the code can
be removed totally unused/unmaintained in the next release.

Thanks,

Mark

Re: [RFC] Deprecate stabs

[Pedro Alves]

Hi!

This subject came up on IRC today.

On 2023-01-19 17:41, Tom Tromey wrote:
> I think it's time to deprecate stabs, and plan to remove all support
> for them.  Stabs are long since obsolete and are not really maintained
> in gdb.  GCC deprecated them in 12 and will remove them as well.


Meanwhile, half a year passed, and GCC 13 is out.

My position with stabs for years had been that, as long as GCC needs it for some ports,
we should keep it.  Since GCC has since removed support for stabs, I think we're now
free to remove it too.

I think we should mark stabs deprecated for GDB 14.  We can discuss more when to actually
remove it, but IMO, the sooner we mark it deprecated, the sooner people will be aware of our
intentions.  FWIW, I do support removing it in GDB 15.

Pedro Alves

> ---
>  gdb/NEWS | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index c0aac212e30..317f6536bc0 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -5,6 +5,9 @@
>  
>  * MI version 1 has been removed.
>  
> +* Support for the stabs debugging format is deprecated, and it will be
> +  removed in GDB 15.
> +
>  * GDB has initial built-in support for the Debugger Adapter Protocol.
>    This support requires that GDB be built with Python scripting
>    enabled.

Re: [RFC] Deprecate stabs

[Tom Tromey]

>> I think it's time to deprecate stabs, and plan to remove all support
>> for them.  Stabs are long since obsolete and are not really maintained
>> in gdb.  GCC deprecated them in 12 and will remove them as well.

Pedro> Meanwhile, half a year passed, and GCC 13 is out.

Pedro> My position with stabs for years had been that, as long as GCC needs it for some ports,
Pedro> we should keep it.  Since GCC has since removed support for stabs, I think we're now
Pedro> free to remove it too.

Pedro> I think we should mark stabs deprecated for GDB 14.  We can discuss more when to actually
Pedro> remove it, but IMO, the sooner we mark it deprecated, the sooner people will be aware of our
Pedro> intentions.  FWIW, I do support removing it in GDB 15.

It's maybe a little late for 14/15 now.

I'm thinking I will send email to gdb@ and push the NEWS patch after the
14 branch is made.  That is, deprecate in 15 and remove in 16.

I have also been wondering if some of the other debug formats are still
relevant.  My suspicion is that they are long since obsolete.

Tom

Re: [RFC] Deprecate stabs

[Eli Zaretskii]

> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>,  gdb-patches@sourceware.org
> Date: Wed, 30 Aug 2023 11:48:09 -0600
> 
> Pedro> My position with stabs for years had been that, as long as GCC needs it for some ports,
> Pedro> we should keep it.  Since GCC has since removed support for stabs, I think we're now
> Pedro> free to remove it too.
> 
> Pedro> I think we should mark stabs deprecated for GDB 14.  We can discuss more when to actually
> Pedro> remove it, but IMO, the sooner we mark it deprecated, the sooner people will be aware of our
> Pedro> intentions.  FWIW, I do support removing it in GDB 15.
> 
> It's maybe a little late for 14/15 now.
> 
> I'm thinking I will send email to gdb@ and push the NEWS patch after the
> 14 branch is made.  That is, deprecate in 15 and remove in 16.
> 
> I have also been wondering if some of the other debug formats are still
> relevant.  My suspicion is that they are long since obsolete.

Not obsolete, broken.  They simply don't work, and for quite some
time.  The few platforms which still need them cannot use the newer
GDB versions.

For example, the DJGPP (a.k.a. "go32") port of Emacs still uses the
COFF debug info, and the latest GDB version that can be used to debug
it is GDB 7.2.  Any newer version simply cannot debug the program, and
either crashes or fails to start the debuggee and take control when
breakpoints are hit.

Re: [RFC] Deprecate stabs

[Kevin Buettner]

On Wed, 30 Aug 2023 11:48:09 -0600
Tom Tromey <tom@tromey.com> wrote:

> >> I think it's time to deprecate stabs, and plan to remove all support
> >> for them.  Stabs are long since obsolete and are not really maintained
> >> in gdb.  GCC deprecated them in 12 and will remove them as well.  
> 
> Pedro> Meanwhile, half a year passed, and GCC 13 is out.  
> 
> Pedro> My position with stabs for years had been that, as long as GCC needs it for some ports,
> Pedro> we should keep it.  Since GCC has since removed support for stabs, I think we're now
> Pedro> free to remove it too.  
> 
> Pedro> I think we should mark stabs deprecated for GDB 14.  We can discuss more when to actually
> Pedro> remove it, but IMO, the sooner we mark it deprecated, the sooner people will be aware of our
> Pedro> intentions.  FWIW, I do support removing it in GDB 15.  
> 
> It's maybe a little late for 14/15 now.
> 
> I'm thinking I will send email to gdb@ and push the NEWS patch after the
> 14 branch is made.  That is, deprecate in 15 and remove in 16.

I'm in favor of this timeline.

Kevin

Re: [RFC] Deprecate stabs

[John Baldwin]

On 8/30/23 10:48 AM, Tom Tromey wrote:
>>> I think it's time to deprecate stabs, and plan to remove all support
>>> for them.  Stabs are long since obsolete and are not really maintained
>>> in gdb.  GCC deprecated them in 12 and will remove them as well.
> 
> Pedro> Meanwhile, half a year passed, and GCC 13 is out.
> 
> Pedro> My position with stabs for years had been that, as long as GCC needs it for some ports,
> Pedro> we should keep it.  Since GCC has since removed support for stabs, I think we're now
> Pedro> free to remove it too.
> 
> Pedro> I think we should mark stabs deprecated for GDB 14.  We can discuss more when to actually
> Pedro> remove it, but IMO, the sooner we mark it deprecated, the sooner people will be aware of our
> Pedro> intentions.  FWIW, I do support removing it in GDB 15.
> 
> It's maybe a little late for 14/15 now.
> 
> I'm thinking I will send email to gdb@ and push the NEWS patch after the
> 14 branch is made.  That is, deprecate in 15 and remove in 16.
> 
> I have also been wondering if some of the other debug formats are still
> relevant.  My suspicion is that they are long since obsolete.

We still haven't branched for 14, so presumably you can still mark it
deprecated in 14?  Users don't really run master I assume, so adding
it to NEWS earlier in 14.x's cycle wouldn't have made a difference I
think?  You can always defer the actual removal of stabs to later
(closer to 15 branching) to leave time for users to voice their input.

-- 
John Baldwin