public inbox for
 help / color / mirror / Atom feed
From: Simon Marchi <>
To: Eli Zaretskii <>, Tom Tromey <>
Subject: Re: [RFC] Deprecate stabs
Date: Tue, 14 Feb 2023 11:36:24 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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


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


  reply	other threads:[~2023-02-14 16:36 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
2023-02-11  8:29         ` Eli Zaretskii
2023-02-14 16:36           ` Simon Marchi [this message]
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:

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

  git send-email \ \ \ \ \ \ \

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