Question about debug mode on branch `nanhu` #2317

HUA-FENG1995 · 2023-09-20T03:22:26Z

使用nanhu分支尝试调试模式，在GDB端对当前pc地址+4打断点，然后run程序，很久都没有跑到断点处，请问这是什么原因？

[TRANSLATION]
Use nanhu branch to try to debug mode, in the GDB side of the current pc address +4 break point, and then run program, did not run to the breakpoint for a long time, what is the reason?

emu端：

openocd端：

config.cfg内容:

gdb端：

huxuan0307 · 2023-09-20T04:58:50Z

把sysbus改成progbuf试试，sysbus读写有点问题

[TRANSLATION]
Try changing sysbus to progbuf. There is something wrong with reading and writing sysbus

huxuan0307 · 2023-09-20T05:08:22Z

另外，请用reset halt代替halt，这样可以让核心停在第一条指令执行之前

[TRANSLATION]
Also, replace halt with reset halt, which stops the core before the first instruction is executed

huxuan0307 · 2023-09-20T05:09:28Z

附上我们使用的openocd.cfg

adapter speed 10000

adapter driver remote_bitbang
remote_bitbang host localhost
remote_bitbang port 23334

set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME 

riscv set_reset_timeout_sec 120
riscv set_command_timeout_sec 30
riscv set_mem_access progbuf
init
reset halt
echo "Halt at reset"
echo "sleep 10000ms"
sleep 10000

echo "Ready for Remote Connections"

HUA-FENG1995 · 2023-09-21T02:04:04Z

还是不行，这次报progbuf=failed
emu版本

emu端：

openocd端：

gdb端：

HUA-FENG1995 · 2023-09-21T02:31:40Z

这会和我的openocd安装不正确有关吗

HUA-FENG1995 · 2023-09-21T03:16:20Z

我安装openocd的命令如下：
./configure [options]
make
make install

请问在./configure那一步是不是需要加些其他的配置

huxuan0307 · 2023-09-28T08:16:14Z

我们最近有同事走了一遍流程，没遇到问题。openocd没有特殊的配置，用的是
riscv-openocd

你可以忽略读0x0这个地址的报错，继续往后调试，因为这可能是riscv-openocd或者riscv-gdb抽风，正常情况下不会有读这个地址的需求。

在openocd的启动命令里指定debug_level=3可以输出更详细的log，从log里你应该可以观察到gdb发出了扫描寄存器的请求，耐心等待扫描完pc和32个通用寄存器后，gdb就可以工作了。

[TRANSLATION]
One of our colleagues recently went through the process and had no problems. openocd has no special configuration; it uses

riscv-openocd

You can ignore the error reading at 0x0 and continue debugging, as this could be a riscv-openocd or riscv-gdb leak, which would not normally be required.

Specifying debug_level=3 in the openocd launch command will output a more detailed log, from which you should observe that gdb asks to scan the registers, and after patiently waiting for the pc and 32 general-purpose registers to be scanned, gdb is ready to work.

读寄存器的过程

Debug: 1188 38712 riscv-013.c:4066 riscv013_get_register(): [riscv.cpu] reading register zero
Debug: 1189 38713 riscv-013.c:785 execute_abstract_command(): command=0x321000; access register, size=64, postexec=0, transfer=1, write=0, regno=0x1000
Debug: 1190 38790 riscv-013.c:402 scan(): 41b w 00321000 @17 -> + 00000000 @00; 3i
Debug: 1191 38876 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1192 38949 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10001002 @16; 3i
Debug: 1193 38949 riscv-013.c:412 scan():  ->  progbufsize=16 busy datacount=2
Debug: 1194 39032 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1195 39102 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10000002 @16; 3i
Debug: 1196 39102 riscv-013.c:412 scan():  ->  progbufsize=16 datacount=2
Debug: 1197 39185 riscv-013.c:402 scan(): 41b r 00000000 @05 -> + 00000000 @00; 3i
Debug: 1198 39257 riscv-013.c:402 scan(): 41b - 00000000 @05 -> + 00000000 @05; 3i
Debug: 1199 39339 riscv-013.c:402 scan(): 41b r 00000000 @04 -> + 00000000 @00; 3i
Debug: 1200 39411 riscv-013.c:402 scan(): 41b - 00000000 @04 -> + 00000000 @04; 3i
Debug: 1201 39411 riscv-013.c:1483 register_read_direct(): [riscv.cpu] zero = 0x0
Debug: 1202 39413 riscv.c:3852 riscv_get_register(): [riscv.cpu] zero: 0
...
Debug: 1684 62010 riscv-013.c:4066 riscv013_get_register(): [riscv.cpu] reading register t6
Debug: 1685 62011 riscv-013.c:785 execute_abstract_command(): command=0x32101f; access register, size=64, postexec=0, transfer=1, write=0, regno=0x101f
Debug: 1686 62102 riscv-013.c:402 scan(): 41b w 0032101f @17 -> + 00000000 @00; 3i
Debug: 1687 62195 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1688 62275 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10001002 @16; 3i
Debug: 1689 62275 riscv-013.c:412 scan():  ->  progbufsize=16 busy datacount=2
Debug: 1690 62370 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1691 62447 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10000002 @16; 3i
Debug: 1692 62447 riscv-013.c:412 scan():  ->  progbufsize=16 datacount=2
Debug: 1693 62539 riscv-013.c:402 scan(): 41b r 00000000 @05 -> + 00000000 @00; 3i
Debug: 1694 62616 riscv-013.c:402 scan(): 41b - 00000000 @05 -> + 00000000 @05; 3i
Debug: 1695 62709 riscv-013.c:402 scan(): 41b r 00000000 @04 -> + 00000000 @00; 3i
Debug: 1696 62787 riscv-013.c:402 scan(): 41b - 00000000 @04 -> + 00000000 @04; 3i
Debug: 1697 62787 riscv-013.c:1483 register_read_direct(): [riscv.cpu] t6 = 0x0
Debug: 1698 62787 riscv.c:3852 riscv_get_register(): [riscv.cpu] t6: 0
Debug: 1699 62788 riscv.c:4243 register_get(): [riscv.cpu] read 0x0000000000000000 from t6 (valid=1)

然后是openocd给gdb发送通用寄存器和PC值

Debug: 1766 65504 gdb_server.c:417 gdb_log_outgoing_packet(): [riscv.cpu] sending packet: $000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000#01

随后gdb应该就可以操作了。

HUA-FENG1995 · 2023-10-05T13:07:02Z

我们最近有同事走了一遍流程，没遇到问题。openocd没有特殊的配置，用的是 riscv-openocd

你可以忽略读0x0这个地址的报错，继续往后调试，因为这可能是riscv-openocd或者riscv-gdb抽风，正常情况下不会有读这个地址的需求。

在openocd的启动命令里指定debug_level=3可以输出更详细的log，从log里你应该可以观察到gdb发出了扫描寄存器的请求，耐心等待扫描完pc和32个通用寄存器后，gdb就可以工作了。

读寄存器的过程

Debug: 1188 38712 riscv-013.c:4066 riscv013_get_register(): [riscv.cpu] reading register zero
Debug: 1189 38713 riscv-013.c:785 execute_abstract_command(): command=0x321000; access register, size=64, postexec=0, transfer=1, write=0, regno=0x1000
Debug: 1190 38790 riscv-013.c:402 scan(): 41b w 00321000 @17 -> + 00000000 @00; 3i
Debug: 1191 38876 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1192 38949 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10001002 @16; 3i
Debug: 1193 38949 riscv-013.c:412 scan():  ->  progbufsize=16 busy datacount=2
Debug: 1194 39032 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1195 39102 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10000002 @16; 3i
Debug: 1196 39102 riscv-013.c:412 scan():  ->  progbufsize=16 datacount=2
Debug: 1197 39185 riscv-013.c:402 scan(): 41b r 00000000 @05 -> + 00000000 @00; 3i
Debug: 1198 39257 riscv-013.c:402 scan(): 41b - 00000000 @05 -> + 00000000 @05; 3i
Debug: 1199 39339 riscv-013.c:402 scan(): 41b r 00000000 @04 -> + 00000000 @00; 3i
Debug: 1200 39411 riscv-013.c:402 scan(): 41b - 00000000 @04 -> + 00000000 @04; 3i
Debug: 1201 39411 riscv-013.c:1483 register_read_direct(): [riscv.cpu] zero = 0x0
Debug: 1202 39413 riscv.c:3852 riscv_get_register(): [riscv.cpu] zero: 0
...
Debug: 1684 62010 riscv-013.c:4066 riscv013_get_register(): [riscv.cpu] reading register t6
Debug: 1685 62011 riscv-013.c:785 execute_abstract_command(): command=0x32101f; access register, size=64, postexec=0, transfer=1, write=0, regno=0x101f
Debug: 1686 62102 riscv-013.c:402 scan(): 41b w 0032101f @17 -> + 00000000 @00; 3i
Debug: 1687 62195 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1688 62275 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10001002 @16; 3i
Debug: 1689 62275 riscv-013.c:412 scan():  ->  progbufsize=16 busy datacount=2
Debug: 1690 62370 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1691 62447 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10000002 @16; 3i
Debug: 1692 62447 riscv-013.c:412 scan():  ->  progbufsize=16 datacount=2
Debug: 1693 62539 riscv-013.c:402 scan(): 41b r 00000000 @05 -> + 00000000 @00; 3i
Debug: 1694 62616 riscv-013.c:402 scan(): 41b - 00000000 @05 -> + 00000000 @05; 3i
Debug: 1695 62709 riscv-013.c:402 scan(): 41b r 00000000 @04 -> + 00000000 @00; 3i
Debug: 1696 62787 riscv-013.c:402 scan(): 41b - 00000000 @04 -> + 00000000 @04; 3i
Debug: 1697 62787 riscv-013.c:1483 register_read_direct(): [riscv.cpu] t6 = 0x0
Debug: 1698 62787 riscv.c:3852 riscv_get_register(): [riscv.cpu] t6: 0
Debug: 1699 62788 riscv.c:4243 register_get(): [riscv.cpu] read 0x0000000000000000 from t6 (valid=1)

然后是openocd给gdb发送通用寄存器和PC值

Debug: 1766 65504 gdb_server.c:417 gdb_log_outgoing_packet(): [riscv.cpu] sending packet: $000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000#01

随后gdb应该就可以操作了。

那请问用的是什么case呢，我用的是Xiangshan目录下ready-to-run的linux.bin，和tests目录下使用命令make ARCH=riscv64-xs编译的*.elf case。

HUA-FENG1995 · 2023-10-07T03:39:47Z

方便的话可以看看你们 gdb 端的情况吗，我每次都是打完一个断点，然后运行命令 c 就卡死了。

[TRANSLATION]
If it is convenient, can you check the situation of your gdb side? I always finish a breakpoint, and then run the command c to get stuck.

huxuan0307 · 2023-10-09T04:57:53Z

方便的话可以看看你们 gdb 端的情况吗，我每次都是打完一个断点，然后运行命令 c 就卡死了。

$ riscv64-unknown-elf-gdb ../nexus-am/apps/jtag_debug/build/jtag_debug-riscv64-xs-flash.elf 
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=riscv64-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../nexus-am/apps/jtag_debug/build/jtag_debug-riscv64-xs-flash.elf...
(gdb) set remotetimeout 100000
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
0x0000000010000000 in _start ()
(gdb) disassemble _start
Dump of assembler code for function _start:
=> 0x0000000010000000 <+0>:     li      s0,0
   0x0000000010000004 <+4>:     auipc   sp,0x70008
   0x0000000010000008 <+8>:     addi    sp,sp,-4 # 0x80008000
   0x000000001000000c <+12>:    lui     a0,0x2
   0x000000001000000e <+14>:    csrs    mstatus,a0
   0x0000000010000012 <+18>:    csrwi   fcsr,0
   0x0000000010000016 <+22>:    jal     ra,0x1000006c <_trm_init>
End of assembler dump.
(gdb) thb 7
Hardware assisted breakpoint 1 at 0x10000034: file nexus-am/apps/jtag_debug/jtag_debug.c, line 7.
(gdb) hb 6
Hardware assisted breakpoint 2 at 0x1000001a: file nexus-am/apps/jtag_debug/jtag_debug.c, line 6.
(gdb) hb 9
Hardware assisted breakpoint 3 at 0x10000042: file nexus-am/apps/jtag_debug/jtag_debug.c, line 9.
(gdb) c
Continuing.

Breakpoint 2, main () at nexus-am/apps/jtag_debug/jtag_debug.c:6
6           for (i = 0; i < 10000; i++) {
(gdb) disassemble main
Dump of assembler code for function main:
=> 0x000000001000001a <+0>:     addi    sp,sp,-32
   0x000000001000001c <+2>:     sd      s1,8(sp)
   0x000000001000001e <+4>:     lui     s1,0x2
   0x0000000010000020 <+6>:     sd      s0,16(sp)
   0x0000000010000022 <+8>:     sd      s2,0(sp)
   0x0000000010000024 <+10>:    sd      ra,24(sp)
   0x0000000010000026 <+12>:    li      s0,0
   0x0000000010000028 <+14>:    auipc   s2,0x1
   0x000000001000002c <+18>:    addi    s2,s2,272 # 0x10001138
   0x0000000010000030 <+22>:    addi    s1,s1,1808 # 0x2710
   0x0000000010000034 <+26>:    mv      a1,s0
   0x0000000010000036 <+28>:    mv      a0,s2
   0x0000000010000038 <+30>:    addiw   s0,s0,1
   0x000000001000003a <+32>:    jal     ra,0x10001106 <printf_>
   0x000000001000003e <+36>:    bne     s0,s1,0x10000034 <main+26>
   0x0000000010000042 <+40>:    ld      ra,24(sp)
   0x0000000010000044 <+42>:    ld      s0,16(sp)
   0x0000000010000046 <+44>:    ld      s1,8(sp)
   0x0000000010000048 <+46>:    ld      s2,0(sp)
   0x000000001000004a <+48>:    li      a0,0
   0x000000001000004c <+50>:    addi    sp,sp,32
   0x000000001000004e <+52>:    ret
End of assembler dump.
(gdb) si
0x000000001000001c      6           for (i = 0; i < 10000; i++) {
(gdb) si
0x000000001000001e      6           for (i = 0; i < 10000; i++) {
(gdb) disassemble main
Dump of assembler code for function main:
   0x000000001000001a <+0>:     addi    sp,sp,-32
   0x000000001000001c <+2>:     sd      s1,8(sp)
=> 0x000000001000001e <+4>:     lui     s1,0x2
   0x0000000010000020 <+6>:     sd      s0,16(sp)
   0x0000000010000022 <+8>:     sd      s2,0(sp)
   0x0000000010000024 <+10>:    sd      ra,24(sp)
   0x0000000010000026 <+12>:    li      s0,0
   0x0000000010000028 <+14>:    auipc   s2,0x1
   0x000000001000002c <+18>:    addi    s2,s2,272 # 0x10001138
   0x0000000010000030 <+22>:    addi    s1,s1,1808 # 0x2710
   0x0000000010000034 <+26>:    mv      a1,s0
   0x0000000010000036 <+28>:    mv      a0,s2
   0x0000000010000038 <+30>:    addiw   s0,s0,1
   0x000000001000003a <+32>:    jal     ra,0x10001106 <printf_>
   0x000000001000003e <+36>:    bne     s0,s1,0x10000034 <main+26>
   0x0000000010000042 <+40>:    ld      ra,24(sp)
   0x0000000010000044 <+42>:    ld      s0,16(sp)
   0x0000000010000046 <+44>:    ld      s1,8(sp)
   0x0000000010000048 <+46>:    ld      s2,0(sp)
   0x000000001000004a <+48>:    li      a0,0
   0x000000001000004c <+50>:    addi    sp,sp,32
   0x000000001000004e <+52>:    ret
End of assembler dump.
(gdb) info b
Num     Type           Disp Enb Address            What
1       hw breakpoint  del  y   0x0000000010000034 in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:7
2       hw breakpoint  keep y   0x000000001000001a in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:6
        breakpoint already hit 1 time
3       hw breakpoint  keep y   0x0000000010000042 in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:9
(gdb) c
Continuing.

Temporary breakpoint 1, main ()
    at nexus-am/apps/jtag_debug/jtag_debug.c:7
7               printf("loop counter %d\n", i);
(gdb) info b
Num     Type           Disp Enb Address            What
2       hw breakpoint  keep y   0x000000001000001a in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:6
        breakpoint already hit 1 time
3       hw breakpoint  keep y   0x0000000010000042 in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:9
(gdb) thb *0x000000001000003a
Hardware assisted breakpoint 4 at 0x1000003a: file nexus-am/apps/jtag_debug/jtag_debug.c, line 7.
(gdb) info b
Num     Type           Disp Enb Address            What
2       hw breakpoint  keep y   0x000000001000001a in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:6
        breakpoint already hit 1 time
3       hw breakpoint  keep y   0x0000000010000042 in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:9
4       hw breakpoint  del  y   0x000000001000003a in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:7
(gdb) c
Continuing.

Temporary breakpoint 4, 0x000000001000003a in main ()
    at nexus-am/apps/jtag_debug/jtag_debug.c:7
7               printf("loop counter %d\n", i);
(gdb) disassemble main
Dump of assembler code for function main:
   0x000000001000001a <+0>:     addi    sp,sp,-32
   0x000000001000001c <+2>:     sd      s1,8(sp)
   0x000000001000001e <+4>:     lui     s1,0x2
   0x0000000010000020 <+6>:     sd      s0,16(sp)
   0x0000000010000022 <+8>:     sd      s2,0(sp)
   0x0000000010000024 <+10>:    sd      ra,24(sp)
   0x0000000010000026 <+12>:    li      s0,0
   0x0000000010000028 <+14>:    auipc   s2,0x1
   0x000000001000002c <+18>:    addi    s2,s2,272 # 0x10001138
   0x0000000010000030 <+22>:    addi    s1,s1,1808 # 0x2710
   0x0000000010000034 <+26>:    mv      a1,s0
   0x0000000010000036 <+28>:    mv      a0,s2
   0x0000000010000038 <+30>:    addiw   s0,s0,1
=> 0x000000001000003a <+32>:    jal     ra,0x10001106 <printf_>
   0x000000001000003e <+36>:    bne     s0,s1,0x10000034 <main+26>
   0x0000000010000042 <+40>:    ld      ra,24(sp)
   0x0000000010000044 <+42>:    ld      s0,16(sp)
   0x0000000010000046 <+44>:    ld      s1,8(sp)
   0x0000000010000048 <+46>:    ld      s2,0(sp)
   0x000000001000004a <+48>:    li      a0,0
   0x000000001000004c <+50>:    addi    sp,sp,32
   0x000000001000004e <+52>:    ret
End of assembler dump.
(gdb) si
0x0000000010001108 in printf_ (format=format@entry=0x10001138 "loop counter %d\n")
    at nexus-am/libs/klib/src/printf.c:865
865       va_start(va, format);
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000000010000cac in _vsnprintf (out=out@entry=0x10000a34 <_out_char>, 
    buffer=buffer@entry=0x80007f70 "cient me\230\177", 
    maxlen=maxlen@entry=18446744073709551615, format=<optimized out>, 
    format@entry=0x10001138 "loop counter %d\n", va=0x80007fa0, va@entry=0x80007f98)
    at nexus-am/libs/klib/src/printf.c:736
736                 idx = _ntoa_long(out, buffer, idx, maxlen, (unsigned int)(value > 0 ? value : 0 - value), value < 0, base, precision, width, flags);
(gdb) info b
Num     Type           Disp Enb Address            What
2       hw breakpoint  keep y   0x000000001000001a in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:6
        breakpoint already hit 1 time
3       hw breakpoint  keep y   0x0000000010000042 in main 
                                                   at nexus-am/apps/jtag_debug/jtag_debug.c:9
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: nexus-am/apps/jtag_debug/build/jtag_debug-riscv64-xs-flash.elf 

Breakpoint 2, main () at nexus-am/apps/jtag_debug/jtag_debug.c:6
6           for (i = 0; i < 10000; i++) {
(gdb) clear 6
Deleted breakpoint 2 
(gdb) clear 9
Deleted breakpoint 3 
(gdb) info b
No breakpoints or watchpoints.
(gdb) monitor reset halt
JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1266 ms). Workaround: increase "set remotetimeout" in GDB
(gdb) info r pc
pc             0x1000001a       0x1000001a <main>
(gdb) si
0x0000000010000004 in _start ()
(gdb) info r pc
pc             0x10000004       0x10000004 <_start+4>
(gdb) q
A debugging session is active.

        Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) y
Detaching from program: jtag_debug-riscv64-xs-flash.elf, Remote target
[Inferior 1 (Remote target) detached]

huxuan0307 · 2023-10-09T05:21:01Z

我们最近有同事走了一遍流程，没遇到问题。openocd没有特殊的配置，用的是 riscv-openocd
你可以忽略读0x0这个地址的报错，继续往后调试，因为这可能是riscv-openocd或者riscv-gdb抽风，正常情况下不会有读这个地址的需求。
在openocd的启动命令里指定debug_level=3可以输出更详细的log，从log里你应该可以观察到gdb发出了扫描寄存器的请求，耐心等待扫描完pc和32个通用寄存器后，gdb就可以工作了。
读寄存器的过程

Debug: 1188 38712 riscv-013.c:4066 riscv013_get_register(): [riscv.cpu] reading register zero
Debug: 1189 38713 riscv-013.c:785 execute_abstract_command(): command=0x321000; access register, size=64, postexec=0, transfer=1, write=0, regno=0x1000
Debug: 1190 38790 riscv-013.c:402 scan(): 41b w 00321000 @17 -> + 00000000 @00; 3i
Debug: 1191 38876 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1192 38949 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10001002 @16; 3i
Debug: 1193 38949 riscv-013.c:412 scan():  ->  progbufsize=16 busy datacount=2
Debug: 1194 39032 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1195 39102 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10000002 @16; 3i
Debug: 1196 39102 riscv-013.c:412 scan():  ->  progbufsize=16 datacount=2
Debug: 1197 39185 riscv-013.c:402 scan(): 41b r 00000000 @05 -> + 00000000 @00; 3i
Debug: 1198 39257 riscv-013.c:402 scan(): 41b - 00000000 @05 -> + 00000000 @05; 3i
Debug: 1199 39339 riscv-013.c:402 scan(): 41b r 00000000 @04 -> + 00000000 @00; 3i
Debug: 1200 39411 riscv-013.c:402 scan(): 41b - 00000000 @04 -> + 00000000 @04; 3i
Debug: 1201 39411 riscv-013.c:1483 register_read_direct(): [riscv.cpu] zero = 0x0
Debug: 1202 39413 riscv.c:3852 riscv_get_register(): [riscv.cpu] zero: 0
...
Debug: 1684 62010 riscv-013.c:4066 riscv013_get_register(): [riscv.cpu] reading register t6
Debug: 1685 62011 riscv-013.c:785 execute_abstract_command(): command=0x32101f; access register, size=64, postexec=0, transfer=1, write=0, regno=0x101f
Debug: 1686 62102 riscv-013.c:402 scan(): 41b w 0032101f @17 -> + 00000000 @00; 3i
Debug: 1687 62195 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1688 62275 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10001002 @16; 3i
Debug: 1689 62275 riscv-013.c:412 scan():  ->  progbufsize=16 busy datacount=2
Debug: 1690 62370 riscv-013.c:402 scan(): 41b r 00000000 @16 -> + 00000000 @00; 3i
Debug: 1691 62447 riscv-013.c:402 scan(): 41b - 00000000 @16 -> + 10000002 @16; 3i
Debug: 1692 62447 riscv-013.c:412 scan():  ->  progbufsize=16 datacount=2
Debug: 1693 62539 riscv-013.c:402 scan(): 41b r 00000000 @05 -> + 00000000 @00; 3i
Debug: 1694 62616 riscv-013.c:402 scan(): 41b - 00000000 @05 -> + 00000000 @05; 3i
Debug: 1695 62709 riscv-013.c:402 scan(): 41b r 00000000 @04 -> + 00000000 @00; 3i
Debug: 1696 62787 riscv-013.c:402 scan(): 41b - 00000000 @04 -> + 00000000 @04; 3i
Debug: 1697 62787 riscv-013.c:1483 register_read_direct(): [riscv.cpu] t6 = 0x0
Debug: 1698 62787 riscv.c:3852 riscv_get_register(): [riscv.cpu] t6: 0
Debug: 1699 62788 riscv.c:4243 register_get(): [riscv.cpu] read 0x0000000000000000 from t6 (valid=1)

然后是openocd给gdb发送通用寄存器和PC值

Debug: 1766 65504 gdb_server.c:417 gdb_log_outgoing_packet(): [riscv.cpu] sending packet: $000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000#01

随后gdb应该就可以操作了。

那请问用的是什么case呢，我用的是Xiangshan目录下ready-to-run的linux.bin，和tests目录下使用命令make ARCH=riscv64-xs编译的*.elf case。

我在nexus-am仓库自己构建的测试，用来测试硬件断点（因为软件断点是用break指令替换原指令实现的，和trigger无关）

// nexus-am/apps/jtag_debug/jtag_debug.c
#include <klib.h>

int main()
{
    int i;
    for (i = 0; i < 10000; i++) {
        printf("loop counter %d\n", i);
    }
    return 0;
}

# nexus-am/apps/jtag_debug/Makefile
NAME = jtag_debug
SRCS = jtag_debug.c
include $(AM_HOME)/Makefile.app

然后

build/emu --flash jtag_debug -i anything --enable-jtag

huxuan0307 · 2023-10-09T05:22:33Z

方便的话可以看看你们 gdb 端的情况吗，我每次都是打完一个断点，然后运行命令 c 就卡死了。

请用info b检查断点的类型，看看是硬件断点还是软件断点的问题

[TRANSLATION]
Check the type of breakpoint with info b to see if it is a hardware or software breakpoint problem

Jeacy · 2023-10-09T08:03:26Z

另外，请用reset halt代替halt，这样可以让核心停在第一条指令执行之前

请问现在香山对于每个hart的run control状态位功能都实现了吗？（halt request，resume ack，halt-on-reset request，hart reset）

[TRANSLATION]
Also, replace halt with reset halt, which stops the core before the first instruction is executed

May I ask whether Xiangshan has implemented the function of run control status bit for each hart? (halt request, resume ack, Halt-on-reset request, hart reset)

Jeacy · 2023-10-09T08:04:20Z

另外，请用reset halt代替halt，这样可以让核心停在第一条指令执行之前

请问现在香山对于每个hart的run control状态位功能都实现了吗？（halt request，resume ack，halt-on-reset request，hart reset）

我看现在代码hart reset功能好像是false的，想确认一下。

HUA-FENG1995 · 2023-10-17T06:47:39Z

请问如果想调试 debug 模式一般用什么方法呀？

[TRANSLATION]
If you want to debug the debug mode, what is the general method?

HUA-FENG1995 · 2023-10-19T01:49:24Z

你好，我调试是使用emu dump 波形命令，没有波形生成。命令如下：
build/emu --flash jtag_debug -i anything --no-diff --enable-jtag -b 0 -e 150000 --max-cycles=150000 --force-dump-result --dump-wave --wave-path ../1.vcd

[TRANSLATION]
Hello, I debug using emu dump waveform command, no waveform generation. The command is as follows:

build/emu --flash jtag_debug -i anything --no-diff --enable-jtag -b 0 -e 150000 --max-cycles=150000 --force-dump-result --dump-wave --wave-path .. /1.vcd

huxuan0307 · 2023-10-31T11:05:40Z

你好，我调试是使用emu dump 波形命令，没有波形生成。命令如下： build/emu --flash jtag_debug -i anything --no-diff --enable-jtag -b 0 -e 150000 --max-cycles=150000 --force-dump-result --dump-wave --wave-path ../1.vcd

你好，麻烦在编译的时候加上EMU_TRACE=1

比如

make emu -j64 EMU_THREADS=16 EMU_TRACE=1

huxuan0307 · 2023-10-31T11:06:21Z

另外，请用reset halt代替halt，这样可以让核心停在第一条指令执行之前

请问现在香山对于每个hart的run control状态位功能都实现了吗？（halt request，resume ack，halt-on-reset request，hart reset）

我找负责的同事问问

HUA-FENG1995 · 2023-11-01T09:34:19Z

你好，我调试是使用emu dump 波形命令，没有波形生成。命令如下： build/emu --flash jtag_debug -i anything --no-diff --enable-jtag -b 0 -e 150000 --max-cycles=150000 --force-dump-result --dump-wave --wave-path ../1.vcd

你好，麻烦在编译的时候加上EMU_TRACE=1

比如
make emu -j64 EMU_THREADS=16 EMU_TRACE=1

好的，谢谢啦

wissygh · 2024-05-14T02:11:33Z

另外，请用reset halt代替halt，这样可以让核心停在第一条指令执行之前

请问现在香山对于每个hart的run control状态位功能都实现了吗？（halt request，resume ack，halt-on-reset request，hart reset）

[TRANSLATION] Also, replace halt with reset halt, which stops the core before the first instruction is executed

May I ask whether Xiangshan has implemented the function of run control status bit for each hart? (halt request, resume ack, Halt-on-reset request, hart reset)

当前这些功能都是支持的

wakafa1 assigned huxuan0307 Sep 20, 2023

huxuan0307 added help wanted Extra attention is needed question Question requiring answer labels Oct 31, 2023

Tang-Haojin changed the title ~~nanhu分支调试模式相关问题~~ Question about debug mode on branch nanhu Dec 27, 2023

wissygh closed this as completed May 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Question about debug mode on branch `nanhu` #2317

Question about debug mode on branch `nanhu` #2317

HUA-FENG1995 commented Sep 20, 2023 •

edited by biquanha

huxuan0307 commented Sep 20, 2023 •

edited by biquanha

huxuan0307 commented Sep 20, 2023 •

edited by biquanha

huxuan0307 commented Sep 20, 2023

HUA-FENG1995 commented Sep 21, 2023

HUA-FENG1995 commented Sep 21, 2023

HUA-FENG1995 commented Sep 21, 2023

huxuan0307 commented Sep 28, 2023 •

edited by biquanha

HUA-FENG1995 commented Oct 5, 2023

HUA-FENG1995 commented Oct 7, 2023 •

edited by biquanha

huxuan0307 commented Oct 9, 2023

huxuan0307 commented Oct 9, 2023

huxuan0307 commented Oct 9, 2023 •

edited by biquanha

Jeacy commented Oct 9, 2023 •

edited by biquanha

Jeacy commented Oct 9, 2023

HUA-FENG1995 commented Oct 17, 2023 •

edited by biquanha

HUA-FENG1995 commented Oct 19, 2023 •

edited by biquanha

huxuan0307 commented Oct 31, 2023

huxuan0307 commented Oct 31, 2023

HUA-FENG1995 commented Nov 1, 2023

wissygh commented May 14, 2024

Question about debug mode on branch nanhu #2317

Question about debug mode on branch nanhu #2317

Comments

HUA-FENG1995 commented Sep 20, 2023 • edited by biquanha

huxuan0307 commented Sep 20, 2023 • edited by biquanha

huxuan0307 commented Sep 20, 2023 • edited by biquanha

huxuan0307 commented Sep 20, 2023

HUA-FENG1995 commented Sep 21, 2023

HUA-FENG1995 commented Sep 21, 2023

HUA-FENG1995 commented Sep 21, 2023

huxuan0307 commented Sep 28, 2023 • edited by biquanha

HUA-FENG1995 commented Oct 5, 2023

HUA-FENG1995 commented Oct 7, 2023 • edited by biquanha

huxuan0307 commented Oct 9, 2023

huxuan0307 commented Oct 9, 2023

huxuan0307 commented Oct 9, 2023 • edited by biquanha

Jeacy commented Oct 9, 2023 • edited by biquanha

Jeacy commented Oct 9, 2023

HUA-FENG1995 commented Oct 17, 2023 • edited by biquanha

HUA-FENG1995 commented Oct 19, 2023 • edited by biquanha

huxuan0307 commented Oct 31, 2023

huxuan0307 commented Oct 31, 2023

HUA-FENG1995 commented Nov 1, 2023

wissygh commented May 14, 2024

Question about debug mode on branch `nanhu` #2317

Question about debug mode on branch `nanhu` #2317

HUA-FENG1995 commented Sep 20, 2023 •

edited by biquanha

huxuan0307 commented Sep 20, 2023 •

edited by biquanha

huxuan0307 commented Sep 20, 2023 •

edited by biquanha

huxuan0307 commented Sep 28, 2023 •

edited by biquanha

HUA-FENG1995 commented Oct 7, 2023 •

edited by biquanha

huxuan0307 commented Oct 9, 2023 •

edited by biquanha

Jeacy commented Oct 9, 2023 •

edited by biquanha

HUA-FENG1995 commented Oct 17, 2023 •

edited by biquanha

HUA-FENG1995 commented Oct 19, 2023 •

edited by biquanha