From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30639 invoked by alias); 22 Feb 2019 19:24:37 -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 30252 invoked by uid 89); 22 Feb 2019 19:24:30 -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=xml, HX-HELO:sk:mail-ua X-HELO: mail-ua1-f67.google.com Received: from mail-ua1-f67.google.com (HELO mail-ua1-f67.google.com) (209.85.222.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 22 Feb 2019 19:24:28 +0000 Received: by mail-ua1-f67.google.com with SMTP id u1so2251642uae.12 for ; Fri, 22 Feb 2019 11:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TFlRTdpkz/MT0tq7NYC7R6fWgFHfZuDm89ny5IDCh7A=; b=It3uc2dKMVozIw/qjY7ynk5Si3EpHFw8ynzkJXpq1KiuDD9axK4iFfAoAPwQ60U4ox UnERlCc23fw6RNhB/qElf9YCm088dbXGr2qxXINnf/kuk3YnjbA9suA8vhEYNd2sSKDE Rc4ScOSZFMavOl6a237nmT240TsnMP0gZ6fTVhmhi/C0leRQWDIeg6Z2u9wnKGEwrItk khzr66XCD4qXjJqjuMI+ygJumrZDb0M+adjeb+/DAsE/0vY3M6yV6tDPWER0jmmwpvwy b9MO0yW/0MopYkujRvtQhvkI+voTS4+X1BIrfrNxJt2RUX/shaVpzcuoCro1+DhqlPzD YPqg== MIME-Version: 1.0 References: <20181108160745.24600-1-andrew.burgess@embecosm.com> <20181114145756.GM16539@embecosm.com> <87r2bz67ol.fsf@tromey.com> In-Reply-To: <87r2bz67ol.fsf@tromey.com> From: Jim Wilson Date: Fri, 22 Feb 2019 19:24:00 -0000 Message-ID: Subject: Re: [PATCH] gdb/riscv: Add target description support To: Tom Tromey Cc: Andrew Burgess , gdb-patches@sourceware.org, Palmer Dabbelt , John Baldwin Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-02/txt/msg00368.txt.bz2 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. 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. 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). (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