From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88367 invoked by alias); 26 Feb 2019 18:22:08 -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 88348 invoked by uid 89); 26 Feb 2019 18:22:07 -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_PASS autolearn=ham version=3.3.2 spammy=asap, numbered X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Feb 2019 18:22:06 +0000 Received: by mail-wm1-f67.google.com with SMTP id c13so2724371wmb.0 for ; Tue, 26 Feb 2019 10:22:05 -0800 (PST) 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:user-agent; bh=r4TSRxT8p8NMSuk1Jti+cpXFfKKKMJDlp7Ry/QzXpDw=; b=YdNeaGSQDBn78Uo4ZLwdxCU1DkpNdyNKnchlMaznt/idS0GdT8dzNyblLKg6Fwjykp 5l1Ab+FyACCSMYPHkIJ5xlIKR2A8PQZL091Z8p8XlWvdZ5PIe7z1yDftLmgWzewHxdJt L9vKm6f25OtNt2RQuJ+qDarIunkvgOpDEcducBSS92lKZ9nl2sJal9PTSjptiHInXQp7 0HDLN2I29p3PQ4PGl2iDb++wApS8pKnuf4h/S5dkPmJ5V1tt2fc8BDVXdc/kqbF81Zla WRMa+vPv9tXTU+948OVdsZQRe7tdvf2Lfpxkl51rU8oxf0MlEBF8Iau5Vz+xL+X8f4Lx TOhw== Return-Path: Received: from localhost ([199.203.143.44]) by smtp.gmail.com with ESMTPSA id w10sm17786674wru.5.2019.02.26.10.22.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Feb 2019 10:22:03 -0800 (PST) Date: Tue, 26 Feb 2019 18:22:00 -0000 From: Andrew Burgess To: Jim Wilson Cc: Joel Brobecker , Tom Tromey , gdb-patches@sourceware.org, Palmer Dabbelt , John Baldwin Subject: Re: [PATCH] gdb/riscv: Add target description support Message-ID: <20190226182201.GH10887@embecosm.com> References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com> <87r2bz67ol.fsf@tromey.com> <20190223205116.GB15942@embecosm.com> <20190226050220.GA30982@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: As a computer, I find your faith in technology amusing. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00446.txt.bz2 * Jim Wilson [2019-02-26 09:26:04 -0800]: > On Mon, Feb 25, 2019 at 9:02 PM Joel Brobecker wrote: > > I think if QEMU sends an XML with the various register description, > > then whatever numbering GDB uses by default will no longer apply, > > and so things should just-work(tm) regardless of what GDB decided > > to do in terms of register numbering. > > Yes, it shouldn't affect qemu until we try to copy the new gdb xml > files into qemu, at which point we might need to update the qemu > gdbstub support to work with the changed register numbers. We can > worry about this later. This issues doesn't need to delay any gdb > work. Jim, if you're happy then I'll go ahead and merge the fix-up patch. I'll summarise the changes in the patch, and what impact I think they will have now I've had a look at the QEMU code (all these changes are identical for 32 and 64 bit)... (1) Added forced register number for register 'zero'. This will have no impact the default register numbering before had the x-registers numbered from 0. I added this just to make the numbering explicit. (2) Added forced register number 33 to the first floating pointer register ($ft0). Again, this should have no impact as the f-registers were traditionally numbered after the 32 x-registers and the program-counter. (3) Renumbered fflags, frm, and fcsr as 66, 67, and 68. This is where the issues will appear for QEMU, Jim's QEMU patch had adopted the "new" default numbering which placed these registers after the floating point registers (so they had become 65, 66, and 67). If we want backward compatibility then we should merge this GDB patch, and fix QEMU asap to avoid having two incompatible versions in the wild. What I don't understand about all this is why QEMU appears to be discarding one of the big benefits of xml register descriptions; the ability to disconnect their register numbering from GDB's register numbering. Jim: I think your comments above indicate you want my fix merged, but if you could just confirm then I'll get it merged. Thanks, Andrew