From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83437 invoked by alias); 23 Feb 2019 20:51:24 -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 82820 invoked by uid 89); 23 Feb 2019 20:51:23 -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=reads, treating, unfortunate, personally X-HELO: mail-wr1-f66.google.com Received: from mail-wr1-f66.google.com (HELO mail-wr1-f66.google.com) (209.85.221.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Feb 2019 20:51:22 +0000 Received: by mail-wr1-f66.google.com with SMTP id r5so5870519wrg.9 for ; Sat, 23 Feb 2019 12:51:21 -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=Ox4kqZaxt7UjNlRsblX8LNlzUGeaEH0dWVJPT6H1MLY=; b=Vkyrf7+nqMUv7u3RSPz6rR0vWrCDNLh7XLjKK1XtO9T4NUVVXqBQkZO0CYHtKmEBnd swPfsK8kNTg3//036muUofw3sURhti2QaqyR/bolkJYZhMfJ5Yr6NFar3d9w53vftXyX 2prI63Ty6X/nysCYnavd7uJ6vtaktfvtH/ry3mILhnRdd6rb+JnOCU0SfNX2u/xQMHpi e8pqQJVJ+fgTzLH4vHgwrh9ju1uOY6WeaDBILdS6Z30KDLQ7CEptdLL9AjLF6f46E2tv bCcXg2lwoiC+526rxmoaiaIjsWXJWjbODzQid4RuLU6q00uittrrPPaEX/NavHyGIBDu duPA== Return-Path: Received: from localhost ([82.166.165.193]) by smtp.gmail.com with ESMTPSA id f134sm4347374wme.31.2019.02.23.12.51.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 23 Feb 2019 12:51:19 -0800 (PST) Date: Sat, 23 Feb 2019 20:51:00 -0000 From: Andrew Burgess To: Jim Wilson Cc: Tom Tromey , gdb-patches@sourceware.org, Palmer Dabbelt , John Baldwin Subject: Re: [PATCH] gdb/riscv: Add target description support Message-ID: <20190223205116.GB15942@embecosm.com> References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com> <87r2bz67ol.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fortune: Think honk if you're a telepath. 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/msg00387.txt.bz2 * Jim Wilson [2019-02-22 11:24:15 -0800]: > On Fri, Feb 22, 2019 at 9:42 AM Tom Tromey wrote: > > With an older gdb (8.2), with remote debugging enabled: > > > > (gdb) p $fflags > > Sending packet: $p42#d6...Ack > > Packet received: 0000000000000000 > > $1 = 0 > >... > > However with a newer gdb, with an older qemu, I get a failure: > > > > Sending packet: $p41#d5...Ack > > Packet received: E14 > > Could not fetch register "fflags"; remote failure reply 'E14' > > > > Here you can see gdb is sending 0x41. > > The renumbering is unfortunate, but there are a lot of historical > problems here, and compatibility with old tools may not be worth the > trouble. We need to make this work right first, before we can worry > about backward compatibility. > > fflags is a CSR not an F register. But gdb is treating it as both an > F register and a CSR which may lead to some confusion. I think we should be OK. The existing CSR feature file should possibly be deleted, it's not actually used right now. When targets supply a target description then the fflags, frm, and fcsr should only be in one feature otherwise (I think, but haven't tested) GDB will get upset. However, I don't think we should prevent bundling the FP status registers in the FP feature set, personally, I think that the argument for having them there is almost as strong as for having them in with the CSRs. > > Also, fflags is not a real register. It is an alias for a field > inside the fcsr register. If gdb is talking to something like > openocd/qemu that can translate fflags to fcsr that is OK, but for a > native riscv-linux gdb trying to read fflags won't do anything useful, > gdb needs to translate fflags into the fcsr field itself or this isn't > going to work. Though maybe we can do something inside one of the > riscv-linux files to handle this. I started working on, and do plan to finish soon(ish) a change where if GDB finds an $fcsr register, but no $fflags or $frm then a pseudo-register would be setup (for each) that just reads/writes the bits for $fcsr. This would work for all targets, so the native linux case should be covered. > > There are a lot of problems with the old qemu gdbstub support. I have > a patch set submitted for qemu to add the gdb xml files and proper > gdbstub support to use them. gdb+qemu works much better with these > patches. This patch set has been approved, and is queued for commit > behind one other patch in progress I think. With this patch, > accessing fflags works with both a system qemu and a user qemu using > the current development gdb (8.3 pre-release). That's great news. Thanks for all your effort on this. Thanks, Andrew > > (gdb) info registers fflags > fflags Sending packet: $p4c#07...Ack > Packet received: 0000000000000000 > Packet p (fetch-register) is supported > 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 > (gdb) > > Jim