From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111864 invoked by alias); 26 Feb 2019 20:30:41 -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 111189 invoked by uid 89); 26 Feb 2019 20:30:25 -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=Hx-languages-length:4002, explain X-HELO: mail-wr1-f67.google.com Received: from mail-wr1-f67.google.com (HELO mail-wr1-f67.google.com) (209.85.221.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Feb 2019 20:30:21 +0000 Received: by mail-wr1-f67.google.com with SMTP id w17so15417760wrn.12 for ; Tue, 26 Feb 2019 12:30:14 -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=6rU44D8MqFELrNBH3X/QDfCnyenfH8npwrq65spzIPs=; b=JnQa1F73SHlAmidw7lvTmxNdet++5LOUdRZ+8hV3OxWMhoUoSGXV+MiWeNgv4hpBs/ 3CpzvSoisbJ2VLXtBQFbrSanyt+v0zQpJqGx2j5Y2r0Z3piHIAlA3528XRz5tvs0PisM gmiCAIpEAJrKCuxtvgn+BxKg/eNYfqOdTs+rUoeDFgsq5tkuOlmDJ87JbPwV4rG0xhu/ OP7fgV6VJ7WF6pgJ5ep6JgDMecpyTyj9JWk3vFGWaWJrZmtS7gtX7Zc1y0Ay+cSUn4Zp E95CpnOQEiqzLd/ycjQQTCNhFXWKc6MrqZrA8S+BoqhkZFRHry43SkhVaONVXzqZWj3I dOfQ== Return-Path: Received: from localhost ([199.203.143.44]) by smtp.gmail.com with ESMTPSA id i12sm22088782wrq.21.2019.02.26.12.30.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Feb 2019 12:30:11 -0800 (PST) Date: Tue, 26 Feb 2019 20:30: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: <20190226203008.GI10887@embecosm.com> References: <20181114145756.GM16539@embecosm.com> <87r2bz67ol.fsf@tromey.com> <20190223205116.GB15942@embecosm.com> <20190226050220.GA30982@adacore.com> <20190226182201.GH10887@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: I'm a nuclear submarine under the polar ice cap and I need a Kleenex! 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/msg00456.txt.bz2 * Jim Wilson [2019-02-26 11:27:24 -0800]: > On Tue, Feb 26, 2019 at 10:40 AM Jim Wilson wrote: > > > (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). > > qemu just assigns numbers to xml regs if they don't have them, > incrementing by one for each reg. If we change the qemu xml files at > the same time as we change the qemu gdbstub hooks, then qemu will > always be internally consistent. These xml register numbers aren't > user visible anywhere inside qemu, they are only used for > communication with gdb. > > > > 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. > > I have no control over qemu. I can only suggest a patch, and ping it, > and maybe in a few months it will get merged in. Sure, I understand that, but I was wrong with the severity of the problem. So, there's no rush on changing QEMU. > > > > 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. > > I don't understand the comment. We still must have numbers for the > registers, otherwise we can't communicate with gdb about them. But > these xml register numbers don't affect the user or hardware register > numbers, the qemu gdbstub converts between hardware register numbers > and xml register numbers. So, I miss-understood the problem slightly, I'll explain what I was trying to say, then explain why it doesn't really matter... Consider this cut-down version the 32bit-fpu.xml for RISC-V: Internally QEMU will have its hardware register number that represents register $ft0, this could be anything, lets pick 105 at random. GDB will also have a number that represents register $ft0, this too could be anything, lets pick 33 at random, this isn't the xml register number you mention above, this is just GDBs internal number. If QEMU sends this to GDB: Then internally GDB will call $ft0 #33, but, when it talks to QEMU it will use #105. If GDB changes its numbering it will continue to use #105 when talking to QEMU. However, what QEMU _actually_ sends is this: An exact copy of GDBs XML file. Without being told how the remote would like to number its registers GDB just numbers the registers in the order that they are sent from the remote, and this establishes fairly arbitrary numbering scheme that QEMU is forced to adopt, if GDB ever changes the feature files and QEMU picks these changes up, then it would have to adopt its GDB <-> QEMU mapping code too. I'd originally worried that without a specified 'regnum' in the transmitted xml GDB would use its _internal_ numbering when talking to QEMU, not the sequence number as its transmitted. By using the sequence number we make this a QEMU problem, not a GDB problem, and that's fine; by which I mean, when QEMU changes its xml, it has to change its own mapping, but a change in GDB doesn't impact QEMU. Phew! Sorry for the long email, but I do understand xml target descriptions more now :) > > > > Jim: I think your comments above indicate you want my fix merged, but > > > if you could just confirm then I'll get it merged. > > Yes, I think this is OK. We can worry about qemu later. OK, will merge shortly... Thanks, Andrew