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
>
next prev parent 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