From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118300 invoked by alias); 6 Jul 2018 03:16: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 118187 invoked by uid 89); 6 Jul 2018 03:16:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=exposure, falling, sk:riscvb, cryptic X-HELO: mail-oi0-f67.google.com Received: from mail-oi0-f67.google.com (HELO mail-oi0-f67.google.com) (209.85.218.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Jul 2018 03:16:27 +0000 Received: by mail-oi0-f67.google.com with SMTP id i12-v6so20844713oik.2 for ; Thu, 05 Jul 2018 20:16:27 -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=HqhKPi/CgEzp2eFF35V5lXw8NVa8U4nEa2Hl5eiRH2M=; b=nj5NmmO8hVJoG0lHqmL7Jyau5rOdyyyow+sZuq4DxWU2JkuyaGiX7EUGfvVhqtEr+K ebInPOeardtWBvF47P8AaEkgP6V32sZLuEEBG/dm+M7BQECZoJcW3rwK1uzyX9F7kLeR E7T+8PNCKd3rtgNNq2H6eOcgJ1wO4ZQkAWfgpy7udM9KrysOnmj9U3/Db/ZfF8smLPaL 8OwvUfKCLhUv6J2N556dNuWgz5pna7/Xlr4J54n+6EXlZtij1IEZjkE2Vg+R0If9u+KO AJ7sdWPXm5+X5RpSfMoNF77qdFf8leOnaezU+yjShd3UW/ig7ap/6fHkXWodGsgcv/Nw Ur/g== MIME-Version: 1.0 Received: by 2002:a9d:4d0d:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 20:16:25 -0700 (PDT) In-Reply-To: References: <20180704001334.27460-1-jimw@sifive.com> From: Tim Newsome Date: Fri, 06 Jul 2018 03:16:00 -0000 Message-ID: Subject: Re: [PATCH] RISC-V: Correct legacy misa register number. To: Jim Wilson Cc: Palmer Dabbelt , gdb-patches@sourceware.org, Andrew Burgess Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-07/txt/msg00141.txt.bz2 As Jim says, gdb connecting through OpenOCD to a legacy RISC-V core benefits from the fallback to reading misa at the old address. Pushing that behavior into OpenOCD feels like it's going to make OpenOCD behave in unexpected ways by special-casing just that one CSR. (It also opens up the door for doing that fora number of other CSRs which used to live at different numbers.) I much prefer the current behavior, where OpenOCD simply reads the CSR requested, and returns an error if it's unavailable. Tim On Wed, Jul 4, 2018 at 9:17 AM, Jim Wilson wrote: > 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 >