From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) by sourceware.org (Postfix) with ESMTPS id 106EF395B80B for ; Tue, 12 May 2020 20:26:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 106EF395B80B Received: by mail-qv1-xf41.google.com with SMTP id r3so7154231qvm.1 for ; Tue, 12 May 2020 13:26:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2Zy5OtcIlSZLiylXU+Q1mmyVPJ8ImROo8U8ym8WwtG8=; b=MDFL8e6eSY+sSAGsHKCZTbtONk4IpGgmt4xlifwofc/VvJCIQbjQj1rnpF0+ZKbLtd hzmf9GXNQ05VgUqqL+NvILSNRHSKXI+X2IpUCuKZTbDDa7Y7Ckdp+vTpy+4eumPx4d27 mbqzSOR1IS/B3w7TJ/ph4LTatwsrtlIg/9ODnUGTN5rDtMtzRurUyqEtjDvIyday9vLa KAQqCpj38kWWwAxDTqVNxKoNacPwsRam41j0aBhhYLoQnL4AMP8cIMHip/pnATjhQ5QD 9wZAOqHorgaw0A6NnTr8ntGvODkRm02ZXh03keIJX2iuqWTJUqT9i2L7b0OHwP/POEHt HkjQ== X-Gm-Message-State: AGi0Pub+F5gUj0U84kkoGsXWJU4pav2tjE21NruWO4DQ5twdSDQvXSp7 7/zI85pJOLm95+jQ30GlyFcNf41LYZAkGZvNX0KJng== X-Google-Smtp-Source: APiQypKxP0r3+LyMiwjYt96SE6YvHEaERouAbMG3jT07c34G1s61cPiqUoBg934chHOwPKLKaPj/1aLnyGnXrUhFxfQ= X-Received: by 2002:a0c:b992:: with SMTP id v18mr19596559qvf.223.1589315210937; Tue, 12 May 2020 13:26:50 -0700 (PDT) MIME-Version: 1.0 References: <0d22aed0-9a24-7369-795d-587ec6b99d11@polymtl.ca> In-Reply-To: <0d22aed0-9a24-7369-795d-587ec6b99d11@polymtl.ca> From: Christian Biesinger Date: Tue, 12 May 2020 15:26:14 -0500 Message-ID: Subject: Re: GDBserver ports cleanup To: Simon Marchi Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-22.2 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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 20:26:53 -0000 On Tue, May 12, 2020 at 11:48 AM Simon Marchi via Gdb-patches 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/