From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id AEC933870886 for ; Tue, 12 May 2020 16:48:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AEC933870886 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 04CGluRJ014324 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 12 May 2020 12:48:00 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 04CGluRJ014324 Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DE6161ED39 for ; Tue, 12 May 2020 12:47:55 -0400 (EDT) To: "gdb-patches@sourceware.org" From: Simon Marchi Subject: GDBserver ports cleanup Message-ID: <0d22aed0-9a24-7369-795d-587ec6b99d11@polymtl.ca> Date: Tue, 12 May 2020 12:47:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 12 May 2020 16:47:56 +0000 X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 16:48:04 -0000 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/