From: Nick Clifton via Gdb <gdb@sourceware.org>
To: Simon Marchi <simark@simark.ca>,
"gdb@sourceware.org" <gdb@sourceware.org>,
Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: Re: RFC: Deprecate the ARM simulator
Date: Mon, 23 Sep 2024 17:34:01 +0100 [thread overview]
Message-ID: <816825de-eb3b-4cea-92a6-90c60e4fa98e@redhat.com> (raw)
In-Reply-To: <71116da4-88e1-4d0c-8f5e-960d880621dc@simark.ca>
Hi Simon,
>> I would like to deprecate or even delete the ARM simulator.
>> It is not entirely clear to me how a sim target should be
>> deprecated. I am attaching a patch that shows one possible
>> method - adding code to the sim
> Thanks for being proactive with this. Is `--enable-obsolete` something
> that already exists?
Not in GDB land. I actually stole the code from the binutils where we use
it when we want to deprecate old targets. First they get moved into the
you-cannot-build-without-enable-obsolete list and then after a release has
been made they get completely deprecated. (Unless someone volunteers to
take over maintainership of the port, but this rarely happens).
The problem is that this entire process is manual. There is no automatic
way of deprecating a port. So it is up to someone to remember to make the
necessary changes. Still at least it does work and we do deprecate things.
> When we deprecate / remove ports in GDB, we currently don't do anything
> like this, if I recall correctly we just announce on the mailing list
> that it will be removed in the next major version, and then later remove
> it. But I think that having it disabled by default and enabled with a
> switch like `--enable-obsolete` is a good idea. People downstream who
> use that feature are not likely to follow the gdb or binutils mailing
> lists, so this will make them notice, and it's still relatively easy for
> them to get the feature back in that release.
Right. If someone cares then they can step up and take over the code.
Cheers
Nick
next prev parent reply other threads:[~2024-09-23 16:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-23 13:31 Nick Clifton via Gdb
2024-09-23 16:17 ` Simon Marchi via Gdb
2024-09-23 16:34 ` Nick Clifton via Gdb [this message]
2024-09-23 16:45 ` Richard Earnshaw (lists) via Gdb
2024-09-24 11:03 ` Maciej W. Rozycki
2024-09-24 14:18 ` Nick Clifton via Gdb
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=816825de-eb3b-4cea-92a6-90c60e4fa98e@redhat.com \
--to=gdb@sourceware.org \
--cc=Richard.Earnshaw@arm.com \
--cc=nickc@redhat.com \
--cc=simark@simark.ca \
/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