From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 7F0E8383F850 for ; Tue, 9 Jun 2020 10:27:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7F0E8383F850 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x430.google.com with SMTP id q11so20705720wrp.3 for ; Tue, 09 Jun 2020 03:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CC+VYEvgYpLHDFyCDyj4kKBad0wMvPjVd0am5/U1dKE=; b=Cn/C5uyrgLx0Jlzg2cIxa8szpOpml/Ngvso3kZoXXzQJB13487aZ0TL72ikF5GNOS+ 2n2BeOFTh18p5xtGEEpBCYkWQ9XEOykD0eF88K2Dytem9uV9YS4CeHqqMIcyZbKSI6Nn xYZbOfdLQGsqeXScnc1ASh9klRX4AMygb5SOqrXVXwN1Y6AcvrKjv6aQYJCEM4iRzz8l 5z/cB37aOdctWBOAh0R7sBJTMCRux1o0FO5ZByq0LE1jVgDAuMipPGMJVW6KLJ/pFhId vvkatCqK3C3KjGi8UEo5qHowNZ8S2/gSdbGCgvTD0EVzH/8vyVAFnIXjAZfVD6/S1vDH wy6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CC+VYEvgYpLHDFyCDyj4kKBad0wMvPjVd0am5/U1dKE=; b=qjNnPc90D1ZsOsM+OnaND6YEklcWCFp/eWYm4AugdpO6UlnNxhqYplC+F0YGknaOCx CUWhyk7O+74GNEoQMPF1Vbn4/sf2SrYKSC8uVprkZsM7I+S903ma7NYhMfidZvcdTPaD QemKZt2eFHh6U+RfdFYeU/0tKSmNL32SSyDVrW1uNUrdnEjOxPknUGTpJSyYgGwczAFD DTcL6J6libK3LvJucf3slEgnuXNQEFmc8Q2LhjlihI5wX/SjktrVsZd25o3lnLwpTxjn knQSvDRSyi83alRc9b8uY23m5M/PTxi+uXpyUyxev4gXVrkZiqd5ovjjsKeq7vm4ISnS t9/A== X-Gm-Message-State: AOAM5311VPidMnud1AWk74zlzt+mAE58SRn7ER2CQsXe3UMEYLwwv3UC g7zQzCF1YcFKUx+w+Qf9I8Fb1EcYi5Y= X-Google-Smtp-Source: ABdhPJzAvo4Jda50eToNMEZmM4tkdqG3PAjdikP2CwBe20wQkRM/ODWnV1M/RGJPoYhjdjg3nGBMNQ== X-Received: by 2002:a5d:4e8c:: with SMTP id e12mr3525719wru.194.1591698458462; Tue, 09 Jun 2020 03:27:38 -0700 (PDT) Received: from localhost (host86-128-12-16.range86-128.btcentralplus.com. [86.128.12.16]) by smtp.gmail.com with ESMTPSA id u12sm2891088wrq.90.2020.06.09.03.27.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 03:27:37 -0700 (PDT) Date: Tue, 9 Jun 2020 11:27:36 +0100 From: Andrew Burgess To: Jim Wilson Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [0/1] RISC-V: Update CSR to priv 1.11. Message-ID: <20200609102736.GD2737@embecosm.com> References: <1584007257-14466-1-git-send-email-nelson.chu@sifive.com> <87r1upefg8.fsf@tromey.com> <20200608213927.GC2737@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.6.15-200.fc31.x86_64 (x86_64) X-Uptime: 09:06:01 up 22:12, 1 user, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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, 09 Jun 2020 10:27:40 -0000 * Jim Wilson [2020-06-08 18:19:17 -0700]: > On Mon, Jun 8, 2020 at 2:39 PM Andrew Burgess > wrote: > > Unless I misunderstand here, you asking why we don't use the xml > > target descriptions? We do. Or we _should_ do. Maybe it's not > > working? Is your target definitely sending back a description? And > > it definitely includes register "dscratch" ? > > qemu does have xml support; I added it. The xml register files were > copied straight from the gdb xml files at the time I wrote the > patches. Unfortunately, no one is actively maintaining this code, or > actively testing it, unless maybe you count Tom who is apparently > testing it, so the xml files no longer match the gdb ones. That's absolutely fine. There's no requirement for QEMU to match GDB[1], GDB's builtin XML files are only looked at in the case where the target doesn't provide one[2]. > The old > qemu version of the files does have a dscratch register because gdb > had it at the time. qemu does have a concept of priv spec version, > but I doubt anyone has given any thought about how to match the xml > files to the priv spec version. Currently, there is a single set of > xml files, and that isn't going to work long term. The list of csr > registers needs to depend on the priv spec version. Absolutely and right now this is totally a qemu issue, it needs to dynamically build the xml based on the type of target that's being emulated. We already do some of this in riscv_create_target_description, when we build the default target description, we select 32 or 64 bit x-regs, and optionally add 32 or 64 bit f-regs based on the features we think the target has (which is based on the file being debugged). In the future we might want to extend this if we do more native RISC-V debugging, this could query the priv level and adjust the csr regs as needed, but I don't have any targets where I could test this. > descratch was > added in priv spec 1.9, and was dropped in 1.11. qemu 4.0 has 1.9.1 > and 1.10 support, so dscratch is a valid register name for priv spec > versions supported by qemu (though qemu is dropping 1.9.1 from the > development tree). Anyways, dscratch needs to work in gdb, adding an > alias sounds like a reasonable solution. I would suggest that if the target provides a description then we should be pretty conservative with which aliases we add. I don't know if adding a dscratch to dscratch0 alias would be something I'm in favour of or not. Though I'm conflicted, because it seems obvious that GDB should create aliases for things like ra/x1 sp/x2, etc, so maybe I'm just x-reg elitist... > There is a DECLARE_CSR_ALIAS > in include/opcode/riscv-opc.h for dscratch and other affected csrs, > but I guess gdb isn't handling those at the moment No but we probably should. I took a quick look at this but ran into some issues. I'm going to try and see if I can get this all figured out. Thanks, Andrew [1] There are some requirements like the target must announce the full set of integer registers, but there's no requirement for an exact match, and as far as CSRs, pretty much anything goes. [2] I'm willing to be convinced that I messed up, but I'm describing what _should_ be happening.