From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11432 invoked by alias); 4 Jul 2018 16:17:51 -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 11323 invoked by uid 89); 4 Jul 2018 16:17:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jul 2018 16:17:49 +0000 Received: by mail-wm0-f68.google.com with SMTP id n17-v6so6680276wmh.2 for ; Wed, 04 Jul 2018 09:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/4aKg4IIoxOlWzgNaOIlEG5HuXCC5IKOx1CHemHxazE=; b=Z9/qN38ClMx/e4py4La67PN0MmsPv4f8AoaMSn6pxl1NmvIQ2lQVRm9oHQjaSTHXAj akK6MoU4Rvay3qVS1pJPD3NPMYfHk16N29TG5TlaV78yOVYNAhZH+s5zxQDnO1vhIQTm WUyZIGyWkc6/vTsLhczrK7zT6c035Y1mErKkaWpcBuILSIccc94I5HBcfjf73kbkMi76 yZoRE+v0k8JAP8BnTDi/DXS83FppZ7o+EnSG7qNU0URcM2vQOBPW926zxYJ8yStfWk+p ZpGi3l6znaGYJOBq+FIvT+ELthSUlebOPRiEnwioSUY6rJzJN47A9/DfZ7P599D2G6p8 xwSw== MIME-Version: 1.0 Received: by 2002:adf:8387:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 09:17:45 -0700 (PDT) In-Reply-To: References: <20180704001334.27460-1-jimw@sifive.com> From: Jim Wilson Date: Wed, 04 Jul 2018 16:17:00 -0000 Message-ID: Subject: Re: [PATCH] RISC-V: Correct legacy misa register number. To: Palmer Dabbelt Cc: Tim Newsome , gdb-patches@sourceware.org, Andrew Burgess Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-07/txt/msg00099.txt.bz2 On Tue, Jul 3, 2018 at 5:35 PM, Palmer Dabbelt wrote: > FWIW, there's no legacy RISC-V hardware that can run a native GDB. Thus the > only mechanism to access this would be via a JTAG debugger, and there's no > ABI spec for those. > > Is there even a reason to have a legacy MISA CSR exposed to GDB? I feel > like we can just handle this in the JTAG debugger and keep this oddity from > slipping into an ABI. > > I'm adding Tim as he might have more context. This is code that gets used for both linux native and embedded cross. So the fact that there is no legacy hardware that can run linux isn't relevant. Gdb is trying to read misa to discover what features exist on the target, C, F, D, etc. It first tries to read the 1.10 misa, and if that fails, it then tries to read the 1.9 misa. If the 1.9 misa fails, then you get a cryptic error about a missing register. But the priv spec says that misa should always exist and always be readable, so I think you can only get the cryptic error from the broken linux support in github riscv/riscv-binutils-gdb. If the misa read returns 0, which is allowed by the priv spec, then gdb looks at the program elf header flags, and assumes the target hardware matches the ELF file. My linux support for now just returns 0, but in the future it might be nice to have ptrace support for reading misa. This would only need to support the 1.10 misa. As far as I know, the legacy misa support should remain. But I don't know how the OpenOCD support works. I suppose you want to make OpenOCD try reading both register numbers if we ask for the 1.10 misa? I don't see the benefit of that. There isn't really any ABI exposure here. It is just a few lines of code in gdb to try to read misa, falling back to the old number if the new number doesn't work. Jim