From: Simon Marchi <simon.marchi@polymtl.ca>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: GDBserver ports cleanup
Date: Tue, 12 May 2020 12:47:55 -0400 [thread overview]
Message-ID: <0d22aed0-9a24-7369-795d-587ec6b99d11@polymtl.ca> (raw)
Hi,
I would like to propose a cleanup in the stale / unused / outdated GDBserver
ports (the same could be done with GDB, but I'm tackling GDBserver for now).
It is a recurring theme that when doing changes in common functions, we need to
change files that we can't build. We sometimes find blatant mistakes that wouldn't
even compile in these files, which shows that nobody is building them. If nobody
is using them, I'd like to remove them, as it takes up some precious developer time
to consider them in our changes. It also confuses people as to why we keep code
that doesn't build in our repo...
Looking at the *-low.cc files, here are the platforms GDBserver supports today:
- linux-aarch32
- linux-aarch64
- linux-arm
- linux-bfin
- linux-cris
- linux-crisv32
- linux-ia64
- linux-m32r
- linux-m68k
- linux-mips
- linux-nios2
- linux-ppc
- linux-riscv
- linux-s390
- linux-sh
- linux-sparc
- linux-tic6x
- linux-tile
- linux-x86
- linux-xtensa
- lynx-i386
- lynx-ppc
- nto-x86
- win32-arm
- win32-i386
The ones I'm thinking should go for sure are lynx (LynxOS) and nto (Neutrino). As
far as I know, it's not possible to build GDBserver for these without having access
to non-publicly available toolchains/sysroots from the vendors, so it's not
reasonable to expect the community to maintain it. And seeing that nobody made changes
specific to these ports in many years, I conclude that nobody is really using that code.
Of course, if somebody has access to them and would like to maintain them, I'm not against
that.
We could also do some cleanup in the linux ones, as there are likely a few architectures
that could be considered obsolete. However, in the case of Linux, somebody motivated
could always build a toolchain and sysroot themselves. For reference, here are the
architectures not currently supported in the upstream Linux kernel:
- bfin (removed in 4.16)
- cris (and crisv32 I guess) (removed in 4.17)
- m32r (removed in 4.16)
- tic6x (I don't think it was ever supported upstream. Looking at this [1], there doesn't
seem to be development since ~2012)
- tile (removed in 4.16)
In my opinion, we should remove the corresponding GDBserver ports, unless somebody shows
interest for them. For reference, Linux 4.16 has been released more than two years ago.
About Windows support for ARM, I don't really know about it. I think that our port
was targeting Windows CE [2], which can probably be considered obsolete. However,
Windows 10 supposedly runs on ARM [3], so it might be relevant to keep it? I don't really
know if the current GDBserver code would help for that or not. In doubt, I won't propose
to remove it.
Please let me know what you think.
Also, does anybody know if you deprecation/removal process is written somewhere? I know
we discussed it in the past, but I can't find it.
Simon
[1] http://www.linux-c6x.org/wiki/index.php/Releases
[2] https://en.wikipedia.org/wiki/Windows_Embedded_Compact
[3] https://docs.microsoft.com/en-us/windows/arm/
next reply other threads:[~2020-05-12 16:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 16:47 Simon Marchi [this message]
2020-05-12 20:26 ` Christian Biesinger
2020-05-13 12:01 ` Pedro Alves
2020-05-13 14:45 ` Simon Marchi
2020-05-13 15:01 ` Pedro Alves
2020-05-13 12:37 ` Luis Machado
2020-05-13 13:11 ` Alan Hayward
2020-05-13 14:47 ` Simon Marchi
2020-05-13 18:36 ` Joseph Myers
2020-05-13 18:40 ` Simon Marchi
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=0d22aed0-9a24-7369-795d-587ec6b99d11@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
/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