Re: GDBserver ports cleanup

[Luis Machado <luis.machado@linaro.org>]

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.