From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by sourceware.org (Postfix) with ESMTPS id 29A3B388A817 for ; Wed, 10 Jun 2020 09:31:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 29A3B388A817 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nelson.chu@sifive.com Received: by mail-io1-xd2a.google.com with SMTP id m81so1414100ioa.1 for ; Wed, 10 Jun 2020 02:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k26BnL5lwyPz8ie2r0mP/5FFA8OXdVa67iU6lWNS3xw=; b=FtM4xsQx3qpHuVqrGwmV74czK3rlpJAc5c7Iog9Tp2ykVbmQwlQ5DZ+0mCJZwRoTjN 1eshtJSXFyFi71xdi1vKcPtEMGGWWH/aifPq7O6NomN104seky05ZTlhEaOseAqHPRit lABxu+w8+p1c28tkKCExS88u/hCmb8ZQDHl9kzLNKYiOt1of4gTV/4ibQHCLeVSZV5zT W2gF+QKPkQEUSOM1y/Ovye/Oe273MXvfe24YIJwe0oKht6OhHpv920i62LmS+z3PXB7N v7pSRIQ+WV3yO25/Vm2yAvL2zDkhFr323BHXlPRTMozc6VxXUxGo96qQsC79nIhuyQfx 9G6w== 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=k26BnL5lwyPz8ie2r0mP/5FFA8OXdVa67iU6lWNS3xw=; b=ugQt/9jCifWNI7C31UBvwdhpNvII83kJugJs2JswUr7t86Je7KIUANR47UKuCmtvPE mLHnI8PkvulUCdCYfRSY1ICOALYPTBVVRHjg0m0QLp+BkVV3Z8Cc8zgAO3mSSG5e0yhn KNVWtAvaZMa3HOLddJJ9PtmCTdyUWTkOaD/0ltexROJuOQAaTMHDaZC1Q1pYkAgpV9gf xyVByfd4ghT8L+tBzE/zMFAy4KppG7ApQPWOJrpILWWCPTMyQ3ruhyEM4/TIzMQhkDQu wUgkG7CIT5aQtiVQCAn8EkBZiIdzNWmZbONec4G1Clfvomq3GE0T0AJ0BbRKxn/7vO5O S0Zw== X-Gm-Message-State: AOAM532P2O0CtwNLH+VqnXx/QFx+DIfl/3LC+9JQlSjYQiYz62ZZrP/m tmySXf3W8jn5wN2tl9bjTbddn6dJwEvxv/jAgPqk5A== X-Google-Smtp-Source: ABdhPJwVXgGfMm/PQ9VqgmTOkWdVv6SnPqiWQf/8i9MXbBptITAnPD2NqVQk0LXgVgvugzPEvLiB0NdtozZ2rPRhVrc= X-Received: by 2002:a02:6305:: with SMTP id j5mr2124239jac.140.1591781471621; Wed, 10 Jun 2020 02:31:11 -0700 (PDT) MIME-Version: 1.0 References: <1584007257-14466-1-git-send-email-nelson.chu@sifive.com> <87r1upefg8.fsf@tromey.com> <20200609173040.GE2737@embecosm.com> <20200609224723.GG2737@embecosm.com> In-Reply-To: <20200609224723.GG2737@embecosm.com> From: Nelson Chu Date: Wed, 10 Jun 2020 17:31:00 +0800 Message-ID: Subject: Re: [RFC] gdb/riscv: Improved register alias name creation To: Andrew Burgess Cc: Jim Wilson , Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 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, 10 Jun 2020 09:31:15 -0000 Hi Andrew, The patch is pretty good to me. Thanks for your quick reply and fix. I have some ideas and minor things when I try to support debug csr for now. On Wed, Jun 10, 2020 at 6:47 AM Andrew Burgess wrote: > * Jim Wilson [2020-06-09 13:14:58 -0700]: > > On Tue, Jun 9, 2020 at 10:30 AM Andrew Burgess > > wrote: > > > Looking then at the final PRIV_SPEC_CLASS_* field for each alias then > > > we can see that currently we only want to take the alias from > > > PRIV_SPEC_CLASS_1P11. For now then this is what I'm using to filter > > > the aliases within GDB. > > > > This will do the right thing, but looks a little funny. It isn't > > quite the right way to express what we want. I do think it is OK for > > now, but we will have to be careful when maintaining binutils that we > > don't break this assumption, or remember to update it when necessary. > > I agree. I certainly open to any other ideas. > > Without making changes to the DECLARE_CSR_ALIAS macro (and I don't > know what changes I would make) I saw my options as either: > > - Ignore DECLARE_CSR_ALIAS, and hard code the "approved" aliases into > GDB. Then it'll never break, we just need to remember to update > the hard coded list when riscv-opc.h changes, or > > - Filter the alias list from riscv-opc.h. > > I went with the second option, partly because, if, from now on RISC-V > doesn't reuse old CSR offsets for new CSRs, then any new aliases > should be compatible.... I hope. I think we already have a consensus - It would be great if we only support an alias with a new name, points at an existing CSR offset, and the new name is a synonym for the existing CSR at that offset. For the current FSF tree, there is only one CSR dscratch is an alias. But I'm going to add the missing debug CSR to upstream, so there should be more aliases in the future, and I think all of them follow our consensus. DECLARE_CSR_ALIAS(dscratch, CSR_DSCRATCH0, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) DECLARE_CSR_ALIAS(mcontrol, CSR_TDATA1, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) DECLARE_CSR_ALIAS(icount, CSR_TDATA1, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) DECLARE_CSR_ALIAS(itrigger, CSR_TDATA1, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) DECLARE_CSR_ALIAS(etrigger, CSR_TDATA1, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) DECLARE_CSR_ALIAS(textra32, CSR_TDATA3, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) DECLARE_CSR_ALIAS(textra64, CSR_TDATA3, CSR_CLASS_DEBUG, PRIV_SPEC_CLASS_NONE, PRIV_SPEC_CLASS_NONE) I think mcontrol, icount, itrigger and etrigger are the aliases to tdata1. They all use 0x7a1 offset, and use type [top 5 bits] to determine which one is used, so I believe they are similar to dscrach and textra[32|64], and it's fine to define them by DECLARE_CSR_ALIAS. The problem is that the debug csr and float csr actually belong to the "unprivileged" CSR rather than privileged ones. That means, they should be controlled by the debug specs and float specs rather than the privileged specs. And in the future, vector CSR are also the unprivileged ones controlled by the vector specs. But for now we don't have a conclusion on how to let users choose the unprivileged specs they want. Therefore, I plan to set their defined and aborted versions to PRIV_SPEC_CLASS_NONE temporarily, including their aliases (DECLARE_CSR_ALIAS). And the PRIV_SPEC_CLASS_NONE will be changed to DEBUG_SPEC_CLASS_XXX and VECTOR_SPEC_CLASS_XXX in the future, according to their CSR_CLASS_DEBUG and CSR_CLASS_V. This will affect your current proposal, so I have an idea, How about Gdb creates the aliases just according to the DECLARE_CSR_ALIAS, and don't need to care about the spec versions for now. Binutils have to make sure that the CSR, which is defined by DECLARE_CSR_ALIAS, must be the case like dscrach and itrigger mentioned above. For the ubadaddr, sbadaddr and others, I assume we will drop them in the future and don't need to worry about them. So I prefer to use another macro rather than DECLARE_CSR_ALIAS to define them. Maybe DECLARE_CSR_ALIAS_TEMP or DECLARE_CSR_ALIAS_1p10? I'm fine to use different ALIAS macros, since there are many meanings for them, and Gdb can choose which ALIAS macros to support. Maybe someday Gdb can recognize the PRIV_SPEC_CLASS_XXX, and what we worry about, like misa and ubadaddr, may not be the troubles anymore. But your current proposal is pretty good to me, so we can discuss this later when we actually meet the problems. :) Thanks Nelson