From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by sourceware.org (Postfix) with ESMTPS id B7AA9393EC31 for ; Wed, 13 May 2020 12:37:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7AA9393EC31 Received: by mail-qk1-x742.google.com with SMTP id f189so11402898qkd.5 for ; Wed, 13 May 2020 05:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BM3DnQr9kgvYE6yvtGW1/lcMePLt7niEVK+z5HJkUBU=; b=Cdv48aYJIL/UEHz95YOdtGEF9J5Ot7yyC3Rx/oyyL+Z8ZR3yaXnKA7RV8BWoi1i5Qu i8diQwGXsjDxL1aylXZL6t9x2r73pPJR9LcGDJ/TUNapuDPXQsTTV93+dKjdT/2wSWkk C5XbbE8PE+gejZN0I3RdduKs6nOhpZV7jpOgMnpLhMMX/WU+BOpl2XZJlMso91gpyQtF dk9vxqSXRI/Pw2Gtf/eU47uKUJLy2VAqxW3cmZMKWOaRCPdvon+BfjQ0tDOvQdsuGHpG ehsQZig7WGpR1vBT1WKGGbSYwPmVQBWJSaKOiVDtVD9t0qtZP9crnsjOMqSdiSRrnP67 duvg== X-Gm-Message-State: AGi0PubLH4OqT2ZL/S4QP+xZhXvsvi7JGHUvokyLFaQOPC6RM4szhAlm rYbJtv4riJ3vQllty/aFamY8AA== X-Google-Smtp-Source: APiQypJTWHj6dnqNkGQ8DxZALTZydvMgDLckRlk/DmXMb5AfQ1+advr1FUy1guvbCERpEFj/aLrm7A== X-Received: by 2002:a37:4e05:: with SMTP id c5mr25664628qkb.232.1589373456830; Wed, 13 May 2020 05:37:36 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:1510:1c7:af77:437a:ffd0? ([2804:7f0:8283:1510:1c7:af77:437a:ffd0]) by smtp.gmail.com with ESMTPSA id z18sm14624582qti.47.2020.05.13.05.37.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2020 05:37:35 -0700 (PDT) Subject: Re: GDBserver ports cleanup To: Christian Biesinger , Simon Marchi Cc: "gdb-patches@sourceware.org" , Alan Hayward References: <0d22aed0-9a24-7369-795d-587ec6b99d11@polymtl.ca> From: Luis Machado Message-ID: <3e8800f5-942e-bae8-283b-c815913ae65a@linaro.org> Date: Wed, 13 May 2020 09:37:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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: Wed, 13 May 2020 12:37:39 -0000 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 > 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.