From: Alan Hayward <Alan.Hayward@arm.com>
To: Luis Machado <luis.machado@linaro.org>
Cc: Christian Biesinger <cbiesinger@google.com>,
Simon Marchi <simon.marchi@polymtl.ca>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
nd <nd@arm.com>
Subject: Re: GDBserver ports cleanup
Date: Wed, 13 May 2020 13:11:29 +0000 [thread overview]
Message-ID: <D51C9149-2502-4113-9074-8820AE69C96E@arm.com> (raw)
In-Reply-To: <3e8800f5-942e-bae8-283b-c815913ae65a@linaro.org>
> 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.
next prev parent reply other threads:[~2020-05-13 13:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 16:47 Simon Marchi
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 [this message]
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=D51C9149-2502-4113-9074-8820AE69C96E@arm.com \
--to=alan.hayward@arm.com \
--cc=cbiesinger@google.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@linaro.org \
--cc=nd@arm.com \
--cc=simon.marchi@polymtl.ca \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).