GDBserver ports cleanup

[Christian Biesinger]

On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
> 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.

If indeed the win32-arm support handles Windows 10, I think it would
be good to keep it, but I am not sure it does -- win32-arm-low.cc does
have these lines:
/* Correct in either endianness.  We do not support Thumb yet.  */
static const unsigned long arm_wince_breakpoint = 0xe6000010;
#define arm_wince_breakpoint_len 4

Note mention of WinCE. Also, I am not so familiar with Thumb but I
believe that's widely used on ARM these days?

So my vote would be to remove this for now and if someone wants to
revive it there's the git history.

Christian

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