From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by sourceware.org (Postfix) with ESMTPS id 78B093858034 for ; Thu, 13 Oct 2022 08:44:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78B093858034 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f43.google.com with SMTP id n12so1694624wrp.10 for ; Thu, 13 Oct 2022 01:44:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TbUUS/O8ngFR4IUWgw9Zu8H7Np0kpP8FacBz6ShyOMc=; b=q/ZPOO6vozrEXzCedsTQUJzyhOIifWIKgWQBIUOVcMpMNzwmdSt0PxKF7znaSMEu6S E44PQGJPertF1osjjk6PSlgsOt3AN3rtzUo4VZCqh9uaXJ03I6NH5IV57kKTsH5Pxipd qz5ZapwHPuUndi23/YywBOxjxN/lgUEpqx/M6BXzBfzdzqXJifbDtCNtoVKCLgFmBFSI VinGRSiBG4qLSHOYy3KqLQNDS02axzf19nEKMbSk7VOQU6KnTPoBufkX/LT8eap9Bg35 z2Egub7jFB57NRLrkBNDUsrXfcmg5XJx7beVzLiRyGGxUBXBmDGhwZDjXHHl4q7QwK2r EkXg== X-Gm-Message-State: ACrzQf0ZE/8rMtd4eqLq+hAyawCT2mqrI316qH7HTc8AET6dRlOK7ReT RvEcxgGY1zF8F5dznkPYaW9U1wDhsK6+lVl1 X-Google-Smtp-Source: AMsMyM5wH+nlhWuEZ0BMknZSYwJtB0cmH92UwUn9q3qBpWIpA6wdCrEIm5k4MVOWC16p3Rd8KBBg1w== X-Received: by 2002:a5d:47cf:0:b0:231:5bdc:1719 with SMTP id o15-20020a5d47cf000000b002315bdc1719mr8047820wrc.518.1665650679529; Thu, 13 Oct 2022 01:44:39 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id c15-20020adfa30f000000b00228d52b935asm1553596wrb.71.2022.10.13.01.44.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 01:44:38 -0700 (PDT) Subject: Re: [PATCH] [Arm] Remove dead FPA code To: Luis Machado , gdb-patches@sourceware.org References: <20220920123012.189293-1-luis.machado@arm.com> <8b615b88-26d8-a480-ad9f-51be749169cb@palves.net> <555eafe1-4314-a68b-a048-67d6f462abf1@arm.com> From: Pedro Alves Message-ID: Date: Thu, 13 Oct 2022 09:44:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <555eafe1-4314-a68b-a048-67d6f462abf1@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 13 Oct 2022 08:44:47 -0000 On 2022-10-13 8:18 a.m., Luis Machado wrote: > On 10/10/22 15:56, Pedro Alves wrote: >>> More recently we've added two new guesses for MVE and M-profile system registers, but it doesn't >>> make sense to do so, as these features are advertised as XML already. >> >> What was the justification for adding them back then, then? >> > > It was meant to support other register sets under a situation where no XML is sent back. Well, that's the reason for all the guesses existing. The question was more about -- why were _those_ particular guesses needed / added? Maybe because such stubs already existed in the wild, and people were using some downstream patched version of GDB to work with them? > Though valid, my feeling is that > it was done mostly as copy/pasting what was already being done for the GPR's/FPA. The documentation isn't exactly clear > on whether one should do it or not. Only a few targets use these guesses (Arm, Mips and Microblaze). It's strictly a backwards compatibility feature. It's explained in the comment: /* For backward-compatibility we allow two 'g' packet lengths with the remote protocol depending on whether FPA registers are supplied. M-profile targets do not have FPA registers, but some stubs already exist in the wild which use a 'g' packet which supplies them albeit with dummy values. The packet format which includes FPA registers should be considered deprecated for M-profile targets. */ static void arm_register_g_packet_guesses (struct gdbarch *gdbarch) { Is there something that could be improved in that comment to make it clearer? > Removing the guesses doesn't buy us much on its own, but there is opportunity to get targets to move > to XML descriptions, which is something easier to work with, more flexible and less error-prone. So it looks > like a step in the right direction. The thing is that the old/existing stubs that don't send an XML don't need the flexibility. They just need to continue working as they do today. Removing the guesses and changing the default g/G packet layout causes pain to _users_ foremost. IMO, removing backwards compatibility just for the sake of it doesn't really help anyone. For new registers/features, XML is how to get the flexibility. So I think the angle should be that we, as maintainers, should not accept adding support for more/new registers without XML tdescs.