GDBserver ports cleanup

[Alan Hayward]

> On 13 May 2020, at 13:37, Luis Machado <luis.machado@linaro.org> wrote:
> 
> On 5/12/20 5:26 PM, Christian Biesinger via Gdb-patches wrote:
>> 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.
> 
> Agreed. I think we should remove it.
> 
> If we need a port of gdbserver for Windows on ARM in the future, we'd benefit from coming up with fresh code to reflect the current state of the architecture.
> 
> I'm cc-ing Alan, in case he has any feedback.

The recent Windows on Arm is AArch64, so I suspect it’d need a win64-aarch64-low.cc.

Agreed that we don’t care about the old windows CE stuff. And given that win32-arm-low.cc is only 160 lines, I don’t think we’re missing much by getting rid of it.

I think tic6x was done by Yao Qi.

Alan.