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

[Sebastian Huber <sebastian.huber@embedded-brains.de>]

On 24/07/18 01:27, Jim Wilson wrote:
> 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.

No problem, enjoy your holidays.

>
> 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?

It looks like an Qemu issue. I use the latest upstream Qemu:

https://git.qemu.org/?p=qemu.git;a=blob;f=target/riscv/gdbstub.c;h=4f919b6c3413dcda62b018e6d3863a9aed273828;hb=HEAD

I set a break point in Qemu to riscv_cpu_gdb_read_register(), this 
function is only called with n in {0, ..., 64}. In the GDB connected to 
Qemu I get this

(gdb) p $misa
$1 = <unavailable>

and the break point doesn't trigger. We have also in Qemu 
(target/riscv/gdbstub.c)

     cc->gdb_read_register = riscv_cpu_gdb_read_register;
     cc->gdb_write_register = riscv_cpu_gdb_write_register;
     cc->gdb_num_core_regs = 65;

If I change this to

     cc->gdb_num_core_regs = 4096 + 65;

then I end up in Qemu with (SIGSEGV)

Thread 1 "qemu-system-ris" hit Breakpoint 2, 0x00007ffff2c6c220 in 
____longjmp_chk () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff2c6c220 in ____longjmp_chk () at /lib64/libc.so.6
#1  0x00007ffff2c6c1f9 in __longjmp_chk () at /lib64/libc.so.6
#2  0x00005555556f7a7f in cpu_loop_exit (cpu=cpu@entry=0x555555e16850) 
at /home/EB/sebastian_h/git-qemu/accel/tcg/cpu-exec-common.c:68
#3  0x00005555556f7ad5 in cpu_loop_exit_restore 
(cpu=cpu@entry=0x555555e16850, pc=pc@entry=93824994209915) at 
/home/EB/sebastian_h/git-qemu/accel/tcg/cpu-exec-common.c:76
#4  0x0000555555732e63 in do_raise_exception_err 
(env=env@entry=0x555555e1eaf8, exception=exception@entry=2, 
pc=93824994209915) at 
/home/EB/sebastian_h/git-qemu/target/riscv/op_helper.c:67
#5  0x0000555555733258 in csr_read_helper (env=0x555555e1eaf8, 
csrno=<optimized out>) at 
/home/EB/sebastian_h/git-qemu/target/riscv/op_helper.c:625
#6  0x000055555573707b in riscv_cpu_gdb_read_register (cs=<optimized 
out>, mem_buf=0x7fffffffa578 "", n=65) at 
/home/EB/sebastian_h/git-qemu/target/riscv/gdbstub.c:36
#7  0x00005555556c0de0 in gdb_handle_packet (s=s@entry=0x555556041e90, 
line_buf=line_buf@entry=0x555556041eac "g") at 
/home/EB/sebastian_h/git-qemu/gdbstub.c:1118
#8  0x00005555556c2369 in gdb_read_byte (ch=55, s=0x555556041e90) at 
/home/EB/sebastian_h/git-qemu/gdbstub.c:1720
#9  0x00005555556c2369 in gdb_chr_receive (opaque=<optimized out>, 
buf=<optimized out>, size=<optimized out>) at 
/home/EB/sebastian_h/git-qemu/gdbstub.c:1931
#10 0x00005555558c6200 in tcp_chr_read (chan=<optimized out>, 
cond=<optimized out>, opaque=<optimized out>) at 
/home/EB/sebastian_h/git-qemu/chardev/char-socket.c:473
#11 0x00007ffff5684015 in g_main_context_dispatch () at 
/usr/lib64/libglib-2.0.so.0
#12 0x0000555555928817 in glib_pollfds_poll () at 
/home/EB/sebastian_h/git-qemu/util/main-loop.c:215
#13 0x0000555555928817 in os_host_main_loop_wait (timeout=<optimized 
out>) at /home/EB/sebastian_h/git-qemu/util/main-loop.c:238
#14 0x0000555555928817 in main_loop_wait (nonblocking=<optimized out>) 
at /home/EB/sebastian_h/git-qemu/util/main-loop.c:497
#15 0x0000555555748ff2 in main_loop () at 
/home/EB/sebastian_h/git-qemu/vl.c:1866
#16 0x00005555556622ab in main (argc=<optimized out>, argv=<optimized 
out>, envp=<optimized out>) at /home/EB/sebastian_h/git-qemu/vl.c:4644

Then some locking issues with the iothread mutex occurred. Afterwards a 
stack overflow in

static int gdb_handle_packet(GDBState *s, const char *line_buf)
{
     CPUState *cpu;
     CPUClass *cc;
     const char *p;
     uint32_t thread;
     int ch, reg_size, type, res;
     uint8_t mem_buf[MAX_PACKET_LENGTH];

since 4096 + 64 registers seems to be quite a lot.

What is the right place for RISC-V Qemu bug reports?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.