GDB Debugging with JTAG on Ariane

[jthoma]

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:

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