This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] RISC-V: Correct legacy misa register number.


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]