Truncated register 16 in remote 'g' packet

[lbmeng]

Use a gdb (configured for RV64) to do remote debugging on a qemu-system-riscv32, it repots: "Truncated register 16 in remote 'g' packet". Is this a known issue?

As a comparison, I can use a gdb (configured for x86_64) to do remote debugging on a qemu-system-i386 target without any issue.

$ gdb

GNU gdb (GDB) 8.0.50.20170724-git
Copyright (C) 2017 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-linux-gnu".
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"...
>>> show architecture 
The target architecture is set automatically (currently riscv:rv32)
>>> target remote :1234
Remote debugging using :1234
Truncated register 16 in remote 'g' packet

[jim-wilson]

I think this is because the qemu XML register set support is incomplete.

[myamada9999]

Hi, All

I also had same issue about gdb and created a patch for rv32.
myamada9999@c621fc5

Now, I can confirm that FreeRTOSv9.0.0 for RISCV_HIFive1_GCC version can run with gdb by this patch. But other kind of issues jim-wilson says remain.

Best Regards

[jim-wilson]

I submitted a qemu patch to make this work with the riscv-gnu-toolchain gdb a couple of months ago but I only did the 64-bit support. Just recently we upgraded riscv-gnu-toolchain to use FSF gdb instead of our local gdb port. FSF gdb has proper 32-bit and 64-bit target description support, so we no longer need xml file hacks in qemu to make this work. I have a prototype patch to fix this. It looks similar to your patch. It copies in the xml files from gdb, and adds the 32-bit support.

There is however a problem with the FSF target description support. The CSR support doesn't work, because the FSF gdb xml files have the CSR registers in documentation order instead of numerical order, and with holes for unallocated numbers. I sent email to the RISC-V gdbd maintainer, and am waiting for a response before proceeding. We can fix the CSR problem by adding code to qemu to map the wrong csr register numbers to the right one. Or we can fix it by fixing the gdb csr xml file, but that requires cooperation with the gdb maintainer, so I wanted to talk to him first.

[myamada9999]

Thank you for information.

Just recently we upgraded riscv-gnu-toolchain to use FSF gdb instead of our local gdb port

Is that the following commit?
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b5ffee3181d157a4d964f62344ac827142e37bde

I sent email to the RISC-V gdbd maintainer, and am waiting for a response before proceeding.

After the reply, you can decide the way, right?
Definitely, gdb without csr support is not good. I'm waiting the fix.

Best Regards,

[jim-wilson]

I just added a pull request #182 to update the gdb stub support, using the FSF GDB xml files, with the 32-bit and CSR support added. I just added a translation table for now for the CSR register numbers. We may have to change this later if the GDB CSR xml file changes.

[myamada9999]

Thanks a lot. I'm using it for now.

[lbmeng]

I just added a pull request #182 to update the gdb stub support, using the FSF GDB xml files, with the 32-bit and CSR support added. I just added a translation table for now for the CSR register numbers. We may have to change this later if the GDB CSR xml file changes.

Jim, for now on which GDB and QEMU commit id should I build to fix this issue? Could you please confirm this?

1. gdb commit id: 044a7fd
2. qemu commit id: 5a7a2f8

My understanding is that I need both GDB and QEMU to support the xml files, right?

[jim-wilson]

Yes, you need both gdb and qemu updated. Any commit from the FSF GDB tree that has the xml files should work, and any commit from riscv-gnu-toolchain that has the FSF gdb version should work. Either upstream qemu with my patch set on the upstream qemu-riscv mailing list, or riscv-qemu with pr #182 should work.

The gdb commit looks correct for riscv-gdb in riscv-gnu-toolchain.

I don't know about qemu. I don't follow qemu development. The one I have in my riscv-qemu tree is
3ee161b
from October. But I was told that qemu development has moved upstream (like gdb), so I haven't bothered to update it. My upstream qemu patch set is a little more recent, and a little better tested, than my riscv-qemu pull request. I have
4f818e7
for my upstream qemu tree. I need to update my upstream qemu patch set and resend it, so if you have comments now would be a good time for that.

[lbmeng]

Jim,

Built a GDB and QEMU from above commit id I mentioned, using GDB to remote debug the QEMU riscv32, this time there is no "Truncated register 16 in remote 'g' packet" message anymore. However it still does not work. See logs below.

(gdb) target remote :1234
Remote debugging using :1234
warning: Target-supplied registers are not supported by the current architecture
0x00001000 in ?? ()
(gdb) show architecture
The target architecture is set automatically (currently riscv:rv32)

[jim-wilson]

Did you apply my gdbstub patches to qemu? Both the github riscv-qemu project and the upstream qemu tree will only work if my gdbstub patches are applied. For riscv-qemu, rebasing unfortunately makes it difficult to see what the patch in pull request #182 is. riscv-qemu is not actively maintained at the moment, so I don't expect that this pull request will be accepted. For upstream qemu, my patches are on the qemu-riscv mailing list and should apply cleanly to a qemu version around the day I submitted them. Unfortunately I sent them to the wrong mailing list, so they haven't been reviewed yet. I need to resubmit them. But I hope to get them accepted and added to upstream qemu, and then they will probably eventually appear in riscv-qemu when the next merge from upstream happens, if anyone is still doing work in this tree. The upstream qemu patches can be found here
http://lists.nongnu.org/archive/html/qemu-riscv/2018-12/msg00055.html

And older version of my gdbstub patches were added to the github riscv-qemu project, but this was a temporary incomplete patch that lacks the rv32 support, and CSR support.

[lbmeng]

I was using 5a7a2f8 from riscv/riscv-qemu. The branch is riscv-all. As I can see from https://github.com/riscv/riscv-qemu/commits/riscv-all, it looks the XML support was merged on that branch.

[lbmeng]

I was using 5a7a2f8 from riscv/riscv-qemu. The branch is riscv-all. As I can see from https://github.com/riscv/riscv-qemu/commits/riscv-all, it looks the XML support was merged on that branch.

Somehow, after I 'make clean' and did a rebuilt, now it is working now. The working commits are

• gdb commit id: 044a7fd
• qemu commit id: 5a7a2f8

Sorry for the false alarm before.