riscvarchive / riscv-binutils-gdb

RISC-V backports for binutils-gdb. Development is done upstream at the FSF.
GNU General Public License v2.0
148 stars 233 forks source link

Registers are interpreted as 64-bit when architecture is set to rv32 #260

Closed NoahRoseLedesma closed 3 years ago

NoahRoseLedesma commented 3 years ago

Hello,

I am implementing a remote stub for an educational rv32 simulator. Currently, when the GDB client requests the contents of the registers via the g packet, my server responds with some dummy data. However, the client only seems to accept my response if the packet contains 528 bytes, despite setting the target architecture to rv32 in the client. I am specifying the architecture with set architecture riscv:rv32. If my server responds to the g packet with 264 bytes (i.e. 33 registers 4-byte wide 2 ASCII digits), I receive the following error from the client:

Truncated register 16 in remote 'g' packet

When I send 528 bytes, the client accepts my packet and displays 64-bit registers.

(gdb) i  r
ra             0xffffffffffffffff   0xffffffffffffffff
sp             0xffffffffffffffff   0xffffffffffffffff
gp             0xffffffffffffffff   0xffffffffffffffff
tp             0xffffffffffffffff   0xffffffffffffffff
t0             0xffffffffffffffff   -1
t1             0xffffffffffffffff   -1
t2             0xffffffffffffffff   -1
fp             0xffffffffffffffff   0xffffffffffffffff
s1             0xffffffffffffffff   -1
a0             0xffffffffffffffff   -1
a1             0xffffffffffffffff   -1
a2             0xffffffffffffffff   -1
a3             0xffffffffffffffff   -1
a4             0xffffffffffffffff   -1
a5             0xffffffffffffffff   -1
a6             0xffffffffffffffff   -1
a7             0xffffffffffffffff   -1
s2             0xffffffffffffffff   -1
s3             0xffffffffffffffff   -1
s4             0xffffffffffffffff   -1
s5             0xffffffffffffffff   -1
s6             0xffffffffffffffff   -1
s7             0xffffffffffffffff   -1
s8             0xffffffffffffffff   -1
s9             0xffffffffffffffff   -1
s10            0xffffffffffffffff   -1
s11            0xffffffffffffffff   -1
t3             0xffffffffffffffff   -1
t4             0xffffffffffffffff   -1
t5             0xffffffffffffffff   -1
t6             0xffffffffffffffff   -1
pc             0xffffffffffffffff   0xffffffffffffffff
(gdb) show architecture 
The target architecture is set to "riscv:rv32".

Is this an issue with my use of the client, my implementation of the server, or GDB itself?

jim-wilson commented 3 years ago

There are no gdb experts here. An FSF GDB mailing list is a better place to ask gdb questions.

Does your stub send back XML? Gdb will try to read an XML target description first, and if the stub doesn't support an XML target description then it has to guess. it will use a binary if it was given one, otherwise it will use default architecture info. All of the known working gdb stubs support XML. The non-XML case will probably never work right. The non-XML case works better if you always provide a binary to gdb to debug first, before trying to connect to the target, where the binary has enough info for gdb to figure out what the target is. Otherwise, configuring a riscv32 gdb instead of a riscv64 gdb might help.

For an example of what gdb is expecting, see the gdb/features/riscv/32bit-cpu.xml file. See the Target Descriptions section of the gdb manual. And see various commands like "maint print xml-tdesc". And optionally see simulators with working xml support, like qemu.

NoahRoseLedesma commented 3 years ago

Adding XML target description support did resolve the issue. Thank you for your help! The behavior of set architecture is misleading here, I created a bug report upstream to clarify.