Re: [PATCH] RISC-V: Don't decrement pc after break.

[Jim Wilson <jimw@sifive.com>]

On Mon, Jul 23, 2018 at 10:24 AM, Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>> The problem with misa is easy to miss, as gdb only tries to read misa
>> if you execute a command that requires info about the target, such as
>> trying to use hardware floating point.  Actually, one of my other
>> patches, the one to remove the pc decrement after a break, modified
>> the code so that we try to read misa when checking to see if
>> compressed breakpoints could be used.  Before it was only checking ELF
>> headers for this, which wasn't right.  This is probably the patch that
>> exposed the bug in your rtems target support.
>
> This could be also a Qemu bug. I have to check this with the debugger tomorrow. The misa should be returned by Qemu in csr_read_helper() (target/riscv/op_helper.c). A "info registers" for example returns only the standard registers. For the CSR registers I get "not available".

Sorry, I see that you did point at the right patch.  I'm on vacation,
and not able to give this my full attention at the moment.

What should happen here is that gdb calls fetch_registers, which then
uses some target specific way to access registers.  In the linux
native support, there is a function defined that uses ptrace to read
registers.  I don't know what happens in the openocd case.  If you are
using target remote, then you are using the fetch_registers call in
remote.c, which means the problem is in the target gdbstub.  Looking
at old qemu in riscv-gnu-toolchain, I see in target-riscv/gdbstub.c in
riscv_cpu_gdb_read_register that it only handles the first 65
registers, which are the int, pc, and fp registers.  Looking at new
qemu in freedom-u-sdk, I see in target/riscv/gdbstub.c that the
riscv_cpu_gdb_read_register function is handling the csrs, and looks
OK.  So maybe the problem is that the qemu you are using is too old?

Jim