Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Richard Earnshaw \(lists\) via Gdb" <gdb@sourceware.org>
To: Nick Clifton <nickc@redhat.com>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: RFC: Deprecate the ARM simulator
Date: Mon, 23 Sep 2024 17:45:24 +0100	[thread overview]
Message-ID: <7f447b75-b472-477f-9ab2-e0b0f17d03f3@arm.com> (raw)
In-Reply-To: <c893d0df-1104-4c99-9194-acccb2252c4d@redhat.com>

On 23/09/2024 14:31, Nick Clifton via Gdb wrote:
> Hi Guys,
> 
>    I would like to deprecate or even delete the ARM simulator.
> 
>    Although I am listed as the maintainer for the sim, I have not
>    made any improvements to it for years and it is completely
>    unable to handle modern ARM cores.  The only updates to the
>    sources in the last few years have been to fix compilation
>    issues, and basically it has bit-rotted away.
> 
>    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/configure.ac file to indicate
>    that the target is deprecated.  An alternative would be to
>    add the sim target to the noconfigdirs list that is constructed
>    in the top level configure.ac file.  Although I think that
>    that list is for components that do not support the target at
>    all, rather than components where the target is deprecated.
> 
>    Anyway, thoughts, comments, suggestions ?
> 
> Cheers
>    Nick

I've no objections to this just being removed entirely; the code is ancient.

+case $target in
+ arm*-*-* | \
+ null)
+    if test "x$enable_obsolete" != xyes; then
+      echo "*** Configuration $targ is obsolete." >&2
+      echo "*** Specify --enable-obsolete to build it anyway." >&2
+      echo "*** Support will be REMOVED in the next major release of 
GDB," >&2
+      echo "*** unless a maintainer comes forward." >&2
+      exit 1
+    fi;;
+esac
+

Won't this break builds for arm users unless they now explicitly specify 
--disable-sim?  That's a bit aggressive, IMO, and might cause problems 
for multi-target builds that want some sims, if available.  We don't 
want to make life harder for those just trying to build gdb.

R.

  parent reply	other threads:[~2024-09-23 16:46 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
2024-09-23 16:45 ` Richard Earnshaw (lists) via Gdb [this message]
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=7f447b75-b472-477f-9ab2-e0b0f17d03f3@arm.com \
    --to=gdb@sourceware.org \
    --cc=Richard.Earnshaw@arm.com \
    --cc=nickc@redhat.com \
    /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