Errors: Debug rv32 elf program in riscv-ovpsim emulator

[Dong Tong]

Hi, all

After run DEBUG_GDB_dhrystone.bat in riscv-ovpsim/examples/dhrystone directory on cygwin enviroment, I want to test the gdb. So errors coming.

What's issue I met?

Dong Tong

td@huawei-td /cygdrive/d/riscv/riscv-compliance/riscv-ovpsim/examples/dhrystone
$ riscv64-unknown-elf-gdb dhrystone.RISCV32.elf
GNU gdb (GDB) 8.2.90.20190228-git
Copyright (C) 2019 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-w64-mingw32 --target=riscv64-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://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 dhrystone.RISCV32.elf...
(gdb) show arch
The target architecture is set automatically (currently riscv:rv32)
(gdb) target remote localhost 14705
localhost 14705: No such file or directory.
(gdb) target remote localhost:14705
Undefined command: "". Try "help".
(gdb) target remote localhost:14705
Remote debugging using localhost:14705
Remote 'g' packet reply is too long (expected 132 bytes, got 260 bytes): 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b00001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[Jim Wilson]

On Thu, Apr 25, 2019 at 7:06 AM Dong Tong <dthom...@gmail.com> wrote:
> (gdb) target remote localhost:14705
> Remote debugging using localhost:14705
> Remote 'g' packet reply is too long (expected 132 bytes, got 260 bytes): 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b00001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

gdb and the target disagree on the number of registers. 32*4 is 128,
+4 for pc, so it looks like gdb thinks the target has only general
purpose registers, and the target claims to have both gp and fp
registers, +128 for fp regs. This works best if you use a gdb with
xml support (which I think you have from the version number), and you
use a target that has a gdbstub that provides an xml register set
description. You didn't specify the target. openocd has been using
xml for a while, and if you have a recent enough qemu then it has xml
support too. If you have your own gdbstub, you should add xml support
to it. Lacking xml support, gdb will try to guess the register set
from the binary, e.g. if you compiled soft-float then gdb will assume
that there are no FP registers. If the target does have FP registers
then this can only work if the target gdbstub has xml support. Maybe
you can configure the target so it doesn't have FP registers? But
using a target with xml gdbstub support is the better choice.

Jim