Re: [RFC] Deprecate stabs

[Simon Marchi <simark@simark.ca>]

> 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