From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49267 invoked by alias); 26 Feb 2019 05:02:31 -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 49255 invoked by uid 89); 26 Feb 2019 05:02:31 -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-Envelope-From:sk:brobeck X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Feb 2019 05:02:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E2B5656054; Tue, 26 Feb 2019 00:02:27 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cThIQ3y4AN5u; Tue, 26 Feb 2019 00:02:27 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2F7FF56050; Tue, 26 Feb 2019 00:02:27 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id ABA48849D1; Tue, 26 Feb 2019 09:02:20 +0400 (+04) Date: Tue, 26 Feb 2019 05:02:00 -0000 From: Joel Brobecker To: Jim Wilson Cc: Andrew Burgess , Tom Tromey , gdb-patches@sourceware.org, Palmer Dabbelt , John Baldwin Subject: Re: [PATCH] gdb/riscv: Add target description support Message-ID: <20190226050220.GA30982@adacore.com> References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com> <87r2bz67ol.fsf@tromey.com> <20190223205116.GB15942@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2019-02/txt/msg00425.txt.bz2 Hello, > On Sat, Feb 23, 2019 at 12:51 PM Andrew Burgess > wrote: > > I think we should be OK. The existing CSR feature file should > > possibly be deleted, it's not actually used right now. > > I added the gdb CSR feature file to qemu in my patch. The lack of > register numbers means I had to add a table to translate the xml CSR > register numbers into actual hardware numbers inside qemu. But this > does work. For the subset of CSRs that both qemu and gdb know about, > I can print register values from gdb and it works. This is an > important feature for people using system qemu to debug bootloaders, > and maybe kernels. This is part of the reason I wrote the qemu > gdbstub support. For user qemu, we don't allow CSR access of course, > other than the ones readable from user space like fcsr. > > (gdb) target remote :1234 > Remote debugging using :1234 > 0x0000000000001000 in ?? () > (gdb) set debug remote 1 > (gdb) info registers misa > misa Sending packet: $pa0#01...Ack > Packet received: 2d11140000000080 > Packet p (fetch-register) is supported > 0x800000000014112d RV64ACDFIMSU > (gdb) > > I'm not sure what adding registers numbers to the gp and fp xml files > will do to the qemu support. I will have to test that. Hopefully > there is no effect unless I add the new files to qemu, in which case I > might need to update the gdbstub support then to match the new > numbers. My understanding is that the qemu copy of the files is > supposed to be the same as the gdb copy of these files, but I'm not an > expert on this. This is true for several targets that I checked. > > OpenOCD also has support for sending a csr xml file to gdb, though of > course it does not use the gdb version of the file. It has (or > creates) ifs own csr xml file. 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. I think the work you're doing in QEMU can only be a good thing which will robustify the debugging, because they will avoid the need to synchronize QEMU and GDB versions. I'd like to suggest we do try to restore the original register numbering in GDB as well, though. I've discovered recently that it's not always so easy to switch to a newer version of QEMU. So I think Andrew's patch, if good, should go in as well (and be backported to GDB 8.3 as well). -- Joel