Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tim Newsome <tim@sifive.com>
To: Jim Wilson <jimw@sifive.com>
Cc: Palmer Dabbelt <palmer@sifive.com>,
	gdb-patches@sourceware.org,
		Andrew Burgess <andrew.burgess@embecosm.com>
Subject: Re: [PATCH] RISC-V: Correct legacy misa register number.
Date: Fri, 06 Jul 2018 03:16:00 -0000	[thread overview]
Message-ID: <CAGDihenXYMs6X2Z6hSGDAjiju783VMyvbx9ndLcPhfxHSOkR2w@mail.gmail.com> (raw)
In-Reply-To: <CAFyWVabePD1G8eS0J5esJDHzL_UFp02_1DqwihmqL5Egf0ByiQ@mail.gmail.com>

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 <jimw@sifive.com> wrote:

> On Tue, Jul 3, 2018 at 5:35 PM, Palmer Dabbelt <palmer@sifive.com> 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
>


  reply	other threads:[~2018-07-06  3:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-04  0:14 Jim Wilson
2018-07-04  0:35 ` Palmer Dabbelt
2018-07-04 16:17   ` Jim Wilson
2018-07-06  3:16     ` Tim Newsome [this message]
     [not found] ` <20180704083410.GD2675@embecosm.com>
2018-07-16 22:01   ` Jim Wilson
2018-07-17 15:40     ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGDihenXYMs6X2Z6hSGDAjiju783VMyvbx9ndLcPhfxHSOkR2w@mail.gmail.com \
    --to=tim@sifive.com \
    --cc=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jimw@sifive.com \
    --cc=palmer@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox