From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104293 invoked by alias); 24 Jul 2018 06:15:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 104101 invoked by uid 89); 24 Jul 2018 06:15:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=4.1 required=5.0 tests=BAYES_00,FOREIGN_BODY,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=E-Mail, EMail, keine, diese X-HELO: dedi548.your-server.de Received: from dedi548.your-server.de (HELO dedi548.your-server.de) (85.10.215.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Jul 2018 06:15:20 +0000 Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fhqbN-0005E5-Vj; Tue, 24 Jul 2018 08:15:18 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fhqbN-000CMo-Ij; Tue, 24 Jul 2018 08:15:17 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 14C9C2A1685; Tue, 24 Jul 2018 08:15:25 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Urvq22hrs2l8; Tue, 24 Jul 2018 08:15:22 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CDFE62A1686; Tue, 24 Jul 2018 08:15:22 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W5HfywZmT9bN; Tue, 24 Jul 2018 08:15:22 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id A60372A1685; Tue, 24 Jul 2018 08:15:22 +0200 (CEST) Subject: Re: [PATCH] RISC-V: Don't decrement pc after break. To: Jim Wilson Cc: gdb-patches@sourceware.org, Andrew Burgess References: <20180717001241.25908-1-jimw@sifive.com> <71103f9b-f83b-7e68-1d56-f30038473936@embedded-brains.de> <1830811266.24706.1532366683342.JavaMail.zimbra@embedded-brains.de> From: Sebastian Huber Message-ID: Date: Tue, 24 Jul 2018 06:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00676.txt.bz2 On 24/07/18 01:27, Jim Wilson wrote: > On Mon, Jul 23, 2018 at 10:24 AM, Sebastian Huber > 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 to= morrow. The misa should be returned by Qemu in csr_read_helper() (target/ri= scv/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=3Dqemu.git;a=3Dblob;f=3Dtarget/riscv/gdbstub.c;h=3D= 4f919b6c3413dcda62b018e6d3863a9aed273828;hb=3DHEAD I set a break point in Qemu to riscv_cpu_gdb_read_register(), this=20 function is only called with n in {0, ..., 64}. In the GDB connected to=20 Qemu I get this (gdb) p $misa $1 =3D and the break point doesn't trigger. We have also in Qemu=20 (target/riscv/gdbstub.c) =C2=A0=C2=A0=C2=A0 cc->gdb_read_register =3D riscv_cpu_gdb_read_register; =C2=A0=C2=A0=C2=A0 cc->gdb_write_register =3D riscv_cpu_gdb_write_register; =C2=A0=C2=A0=C2=A0 cc->gdb_num_core_regs =3D 65; If I change this to =C2=A0=C2=A0=C2=A0 cc->gdb_num_core_regs =3D 4096 + 65; then I end up in Qemu with (SIGSEGV) Thread 1 "qemu-system-ris" hit Breakpoint 2, 0x00007ffff2c6c220 in=20 ____longjmp_chk () from /lib64/libc.so.6 (gdb) bt #0=C2=A0 0x00007ffff2c6c220 in ____longjmp_chk () at /lib64/libc.so.6 #1=C2=A0 0x00007ffff2c6c1f9 in __longjmp_chk () at /lib64/libc.so.6 #2=C2=A0 0x00005555556f7a7f in cpu_loop_exit (cpu=3Dcpu@entry=3D0x555555e16= 850)=20 at /home/EB/sebastian_h/git-qemu/accel/tcg/cpu-exec-common.c:68 #3=C2=A0 0x00005555556f7ad5 in cpu_loop_exit_restore=20 (cpu=3Dcpu@entry=3D0x555555e16850, pc=3Dpc@entry=3D93824994209915) at=20 /home/EB/sebastian_h/git-qemu/accel/tcg/cpu-exec-common.c:76 #4=C2=A0 0x0000555555732e63 in do_raise_exception_err=20 (env=3Denv@entry=3D0x555555e1eaf8, exception=3Dexception@entry=3D2,=20 pc=3D93824994209915) at=20 /home/EB/sebastian_h/git-qemu/target/riscv/op_helper.c:67 #5=C2=A0 0x0000555555733258 in csr_read_helper (env=3D0x555555e1eaf8,=20 csrno=3D) at=20 /home/EB/sebastian_h/git-qemu/target/riscv/op_helper.c:625 #6=C2=A0 0x000055555573707b in riscv_cpu_gdb_read_register (cs=3D, mem_buf=3D0x7fffffffa578 "", n=3D65) at=20 /home/EB/sebastian_h/git-qemu/target/riscv/gdbstub.c:36 #7=C2=A0 0x00005555556c0de0 in gdb_handle_packet (s=3Ds@entry=3D0x555556041= e90,=20 line_buf=3Dline_buf@entry=3D0x555556041eac "g") at=20 /home/EB/sebastian_h/git-qemu/gdbstub.c:1118 #8=C2=A0 0x00005555556c2369 in gdb_read_byte (ch=3D55, s=3D0x555556041e90) = at=20 /home/EB/sebastian_h/git-qemu/gdbstub.c:1720 #9=C2=A0 0x00005555556c2369 in gdb_chr_receive (opaque=3D,=20 buf=3D, size=3D) at=20 /home/EB/sebastian_h/git-qemu/gdbstub.c:1931 #10 0x00005555558c6200 in tcp_chr_read (chan=3D,=20 cond=3D, opaque=3D) at=20 /home/EB/sebastian_h/git-qemu/chardev/char-socket.c:473 #11 0x00007ffff5684015 in g_main_context_dispatch () at=20 /usr/lib64/libglib-2.0.so.0 #12 0x0000555555928817 in glib_pollfds_poll () at=20 /home/EB/sebastian_h/git-qemu/util/main-loop.c:215 #13 0x0000555555928817 in os_host_main_loop_wait (timeout=3D) at /home/EB/sebastian_h/git-qemu/util/main-loop.c:238 #14 0x0000555555928817 in main_loop_wait (nonblocking=3D)=20 at /home/EB/sebastian_h/git-qemu/util/main-loop.c:497 #15 0x0000555555748ff2 in main_loop () at=20 /home/EB/sebastian_h/git-qemu/vl.c:1866 #16 0x00005555556622ab in main (argc=3D, argv=3D, envp=3D) at /home/EB/sebastian_h/git-qemu/vl.c:4644 Then some locking issues with the iothread mutex occurred. Afterwards a=20 stack overflow in static int gdb_handle_packet(GDBState *s, const char *line_buf) { =C2=A0=C2=A0=C2=A0 CPUState *cpu; =C2=A0=C2=A0=C2=A0 CPUClass *cc; =C2=A0=C2=A0=C2=A0 const char *p; =C2=A0=C2=A0=C2=A0 uint32_t thread; =C2=A0=C2=A0=C2=A0 int ch, reg_size, type, res; =C2=A0=C2=A0=C2=A0 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? --=20 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=C3=A4ftliche Mitteilung im Sinne des EHUG.