11-26-2019, 09:58 AM
Hi,
I have problems using the JTAG debugging connection with GDB for the Ariane Softcore. The Genesys 2 Board is connected to my PC via JTAG. I have OpenOCD with RISC-V support installed on my machine and it seems to connect just fine:
This does look quite similar to the output in the Ariane git with the exception of this line:
Info : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
I don't know whether this causes the problem or not gdb seems to connect just fine.
Okay, now to the actual problem. If I connect gdb and load the binary (a simple hello world), the PC points to _start. Unfortunately, _start contains loads of unimp instructions and does not redirect the program flow to the main function. Thus, if I do a continue, nothing happens. Same goes for break main etc. as the main function is apparently never called. See the GDB output below:
Interestingly, if I disassemble the _start function in a local GDB Session, it looks like this:
Am I missing something here? Do I need an extra GDB command to load the _start funtion or does it have to be compiled in a specific way? I compiled the binary with riscv64-unknown-elf-gcc test.c -o out and also tried adding -ffreestanding.
Thank you!
- Jan
I have problems using the JTAG debugging connection with GDB for the Ariane Softcore. The Genesys 2 Board is connected to my PC via JTAG. I have OpenOCD with RISC-V support installed on my machine and it seems to connect just fine:
Code:
~/Desktop/ariane $ openocd -f fpga/ariane.cfg
Open On-Chip Debugger 0.10.0+dev-00828-gde00906eb (2019-11-25-14:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Info : datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1 harts
Info : hart 0: XLEN=64, misa=0x800000000014112d
Info : Listening on port 3333 for gdb connections
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
This does look quite similar to the output in the Ariane git with the exception of this line:
Info : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
I don't know whether this causes the problem or not gdb seems to connect just fine.
Okay, now to the actual problem. If I connect gdb and load the binary (a simple hello world), the PC points to _start. Unfortunately, _start contains loads of unimp instructions and does not redirect the program flow to the main function. Thus, if I do a continue, nothing happens. Same goes for break main etc. as the main function is apparently never called. See the GDB output below:
Code:
Reading symbols from ./out...
(gdb) target extended-remote :3333
Remote debugging using :3333
0x000000000001071c in _vfprintf_r ()
(gdb) load
Loading section .text, size 0xbd2c lma 0x100b0
Loading section .rodata, size 0xd08 lma 0x1bde0
Loading section .eh_frame, size 0x4 lma 0x1dae8
Loading section .init_array, size 0x10 lma 0x1daf0
Loading section .fini_array, size 0x8 lma 0x1db00
Loading section .data, size 0x1100 lma 0x1db08
Loading section .sdata, size 0x58 lma 0x1ec08
Start address 0x100c6, load size 56232
Transfer rate: 47 KB/sec, 5623 bytes/write.
(gdb) where
#0 0x00000000000100c6 in _start ()
(gdb) x/5i $pc
=> 0x100c6 <_start>: unimp
0x100c8 <_start+2>: unimp
0x100ca <_start+4>: unimp
0x100cc <_start+6>: unimp
0x100ce <_start+8>: unimp
(gdb) cont
Continuing.
Interestingly, if I disassemble the _start function in a local GDB Session, it looks like this:
Code:
(gdb) disassemble _start
Dump of assembler code for function _start:
0x00000000000100c6 <+0>: auipc gp,0xe
0x00000000000100ca <+4>: addi gp,gp,1066 # 0x1e4f0 <__malloc_av_+248>
0x00000000000100ce <+8>: addi a0,gp,1904
0x00000000000100d2 <+12>: auipc a2,0xf
0x00000000000100d6 <+16>: addi a2,a2,-994 # 0x1ecf0
0x00000000000100da <+20>: sub a2,a2,a0
0x00000000000100dc <+22>: li a1,0
0x00000000000100de <+24>: jal ra,0x1020c <memset>
0x00000000000100e2 <+28>: auipc a0,0x9
0x00000000000100e6 <+32>: addi a0,a0,-1238 # 0x18c0c <atexit>
0x00000000000100ea <+36>: beqz a0,0x100f8 <_start+50>
0x00000000000100ec <+38>: auipc a0,0x2
0x00000000000100f0 <+42>: addi a0,a0,1108 # 0x12540 <__libc_fini_array>
0x00000000000100f4 <+46>: jal ra,0x18c0c <atexit>
0x00000000000100f8 <+50>: jal ra,0x101a2 <__libc_init_array>
0x00000000000100fc <+54>: lw a0,0(sp)
0x00000000000100fe <+56>: addi a1,sp,8
0x0000000000010100 <+58>: li a2,0
0x0000000000010102 <+60>: jal ra,0x1015c <main>
0x0000000000010106 <+64>: j 0x10184 <exit>
Am I missing something here? Do I need an extra GDB command to load the _start funtion or does it have to be compiled in a specific way? I compiled the binary with riscv64-unknown-elf-gcc test.c -o out and also tried adding -ffreestanding.
Thank you!
- Jan