GDBserver ports cleanup

GDBserver ports cleanup

[Simon Marchi]

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/

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

Re: GDBserver ports cleanup

[Pedro Alves]

On 5/12/20 9:26 PM, Christian Biesinger via Gdb-patches wrote:
> On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches

>> 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.
win32-arm support in gdbserver is only for Windows CE.  I was the one
who wrote it, it was the reason I got into GDB hacking in the first
place.  :-)  There was no Windows for ARM back then.  

I don't object removing it.  I haven't built a compiler or gdbserver
for WinCE in years, and I doubt anyone else has^W^W^W^W^W^W^W^W^W^W^W^W
Wow, I just found out that someone forked my old cegcc project, and
updated it based on a much more modern GCC:
https://max.kellermann.name/projects/cegcc/
I had no idea.  Look like he has some local GDB in his github, though
dated from 2016/2018.

If you do remove it, then you'll want to remove all the code guarded under
_WIN32_WCE in win32-low.cc, and also wincecompat.c.  There's also
ARM WinCE support on the GDB side, in arm-wince-tdep.c.

I'm not sure there's that much salvageable for an eventual Windows for ARM
port.  For example, Windows for ARM is strictly Thumb-2, while I don't recall
ever considering Thumb-2 back then.  WinCE was FPA, I believe, while Windows
for ARM is VFP.  The ABIs are just different, and WinCE is weird beyond belief.
(no "errno", no concept for "current directory", etc.).

Other than nostalgia for being what got me into GDB, I really won't miss it
myself.

Thanks,
Pedro Alves

Re: GDBserver ports cleanup

[Luis Machado]

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.

Re: 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.

Re: GDBserver ports cleanup

[Simon Marchi]

On 2020-05-13 8:01 a.m., Pedro Alves wrote:
> On 5/12/20 9:26 PM, Christian Biesinger via Gdb-patches wrote:
>> On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches
> 
>>> 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.
> win32-arm support in gdbserver is only for Windows CE.  I was the one
> who wrote it, it was the reason I got into GDB hacking in the first
> place.  :-)  There was no Windows for ARM back then.  
> 
> I don't object removing it.  I haven't built a compiler or gdbserver
> for WinCE in years, and I doubt anyone else has^W^W^W^W^W^W^W^W^W^W^W^W
> Wow, I just found out that someone forked my old cegcc project, and
> updated it based on a much more modern GCC:
> https://max.kellermann.name/projects/cegcc/
> I had no idea.  Look like he has some local GDB in his github, though
> dated from 2016/2018.
> 
> If you do remove it, then you'll want to remove all the code guarded under
> _WIN32_WCE in win32-low.cc, and also wincecompat.c.  There's also
> ARM WinCE support on the GDB side, in arm-wince-tdep.c.
> 
> I'm not sure there's that much salvageable for an eventual Windows for ARM
> port.  For example, Windows for ARM is strictly Thumb-2, while I don't recall
> ever considering Thumb-2 back then.  WinCE was FPA, I believe, while Windows
> for ARM is VFP.  The ABIs are just different, and WinCE is weird beyond belief.
> (no "errno", no concept for "current directory", etc.).
> 
> Other than nostalgia for being what got me into GDB, I really won't miss it
> myself.

Thanks for the storytelling, I enjoyed it :).

If removing support for WinCE ends up simplifying win32-low.cc, it is a net gain,
since that file is used today.

Simon

Re: GDBserver ports cleanup

[Simon Marchi]

On 2020-05-13 9:11 a.m., Alan Hayward wrote:
> 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.

Thanks both for your input.

Simon

Re: GDBserver ports cleanup

[Pedro Alves]

On 5/13/20 3:45 PM, Simon Marchi wrote:

> Thanks for the storytelling, I enjoyed it :).
> 

:-)

> If removing support for WinCE ends up simplifying win32-low.cc, it is a net gain,
> since that file is used today.

Yes, and removing all that should make it easier to continue the effort to merging
gdb's windows-nat.c and gdbserver's win32-low.cc.

Thanks,
Pedro Alves

Re: GDBserver ports cleanup

[Joseph Myers]

On Tue, 12 May 2020, Simon Marchi via Gdb-patches wrote:

> - tic6x (I don't think it was ever supported upstream.  Looking at this [1], there doesn't
>   seem to be development since ~2012)

I've no idea whether Linux on C6x is actively maintained, but the port is 
there in arch/c6x/.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GDBserver ports cleanup

[Simon Marchi]

On 2020-05-13 2:36 p.m., Joseph Myers wrote:
> On Tue, 12 May 2020, Simon Marchi via Gdb-patches wrote:
> 
>> - tic6x (I don't think it was ever supported upstream.  Looking at this [1], there doesn't
>>   seem to be development since ~2012)
> 
> I've no idea whether Linux on C6x is actively maintained, but the port is 
> there in arch/c6x/.

Oh, my bad, I missed it.  I don't propose to remove this one then.

Simon