From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20395 invoked by alias); 22 Feb 2019 17:42:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20366 invoked by uid 89); 22 Feb 2019 17:42:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1873, packet X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Feb 2019 17:42:54 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway32.websitewelcome.com (Postfix) with ESMTP id A19363E084 for ; Fri, 22 Feb 2019 11:42:53 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id xEqbgThB12qH7xEqbgztat; Fri, 22 Feb 2019 11:42:53 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZwXd6/J25zke02CbwMdJjc7uUEr5Bo7MqeO8+UGdCQg=; b=v07o+eIMBuORg1LAemA2/Pg33c 0EWQ2rqJT7JadIYhqtf+9BbPwrYSgkqFf5tZuyyekbpcAYFCxVMmd8n/y8FQectPymS/cJmCvmUpu J9CkVSMBOqUhR/k19cWQ3nX62; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:49950 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gxEqa-000KgT-Pl; Fri, 22 Feb 2019 11:42:53 -0600 From: Tom Tromey To: Andrew Burgess Cc: gdb-patches@sourceware.org, jimw@sifive.com, palmer@sifive.com, jhb@FreeBSD.org Subject: Re: [PATCH] gdb/riscv: Add target description support References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com> Date: Fri, 22 Feb 2019 17:42:00 -0000 In-Reply-To: <20181114145756.GM16539@embecosm.com> (Andrew Burgess's message of "Wed, 14 Nov 2018 14:57:57 +0000") Message-ID: <87r2bz67ol.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-02/txt/msg00366.txt.bz2 >>>>> "Andrew" == Andrew Burgess writes: Andrew> This is a slightly revised version of the RISC-V target descriptions Andrew> patch. I'm seeing a difference that I think was introduced by this patch and I am wondering whether it is intentional and whether something ought to be done about it. I'm really not sure, this is my first foray into RISC-V and into target descriptions. With an older gdb (8.2), with remote debugging enabled: (gdb) p $fflags Sending packet: $p42#d6...Ack Packet received: 0000000000000000 $1 = 0 Here you can see that gdb thinks the register number for fflags is 0x42. And, that is the value of RISCV_CSR_FFLAGS_REGNUM, even in today's gdb master: (top-gdb) p/x RISCV_CSR_FFLAGS_REGNUM $1 = 0x42 However with a newer gdb, with an older qemu, I get a failure: Sending packet: $p41#d5...Ack Packet received: E14 Could not fetch register "fflags"; remote failure reply 'E14' Here you can see gdb is sending 0x41. RISCV_CSR_FFLAGS_REGNUM is computed by: RISCV_LAST_FP_REGNUM = 64, /* Last Floating Point Register */ RISCV_FIRST_CSR_REGNUM = 65, /* First CSR */ [...] #define DECLARE_CSR(name, num) \ RISCV_ ## num ## _REGNUM = RISCV_FIRST_CSR_REGNUM + num, Then from riscv-opc.h: #define CSR_FFLAGS 0x1 [...] DECLARE_CSR(fflags, CSR_FFLAGS) So, in effect it is RISCV_LAST_FP_REGNUM + 2. But then, e.g., in the 32-bit FPU description: Andrew> +static int Andrew> +create_feature_riscv_32bit_fpu (struct target_desc *result, long regnum) Andrew> +{ [...] Andrew> + tdesc_create_reg (feature, "ft11", regnum++, 1, NULL, 32, "ieee_single"); Andrew> + tdesc_create_reg (feature, "fflags", regnum++, 1, NULL, 32, "int"); I think this is where the discrepancy lies. I'm not really sure what ought to be done here. Do you have any ideas? thanks, Tom