Closed rohgarg closed 5 years ago
riscv-binutils-gdb has a working bare metal gdb, but only if you check out the right branch. Building riscv-gnu-toolchain will give you the right branch. The riscv linux support is probably not working, and if it is working, it probably only works on core dumps.
GDB 8.1 doesn't have riscv support. GDB 8.2 has only bare metal riscv support, for use with openocd. There is a branch for it in the FSF GDB tree, but it hasn't been released yet, it should come out soon. I just added native riscv linux support last week, so this is in top of tree gdb sources and will appear in gdb 8.3, which probably comes out early next year. Most basic features are working, but there is a lot more work required to get a fully working gdb port. There is no gdbserver support yet.
If it is the riscv-linux native support you are interested in, then you can build it from the gdb top of tree sources. However, there are 3 required linux kernel patches, one optional linux kernel patch, and one optional glibc patch, none of which are in the riscv Fedora 28 distro at this time. I don't know if or when they will be added. The kernel is pretty easy to rebuild with patches. Glibc is not.
You can find info on the linux kernel and glibc patches here https://github.com/jim-wilson/riscv-linux-native-gdb/blob/jimw-riscv-linux-gdb/README.md and a copy of the linux kernel patches I'm currently using here https://github.com/jim-wilson/riscv-linux-native-gdb/blob/jimw-riscv-linux-gdb/riscv-linux.txt But I don't recommend using this source tree anymore. Use the FSF GDB top of tree sources instead. https://sourceware.org/gdb/current/
Thanks for the suggestions, Jim. I'll give this a shot and see where it leads.
Hi, I compiled FSF GDB (v. 8.1.1) and also top-of-tree from the
riscv-binutils-gdb
repository directly on the QEMU RISCV64 emulator, with Fedora-28, Linux kernel version 4.15.0-00049, and gcc-7.3.1. I used the./configure && make
command to configure and build.In both of the cases, gdb fails with the following error.
The kernel prints the following error trace on the terminal:
(I suppose the big issue here is the unrecognized architecture, and signal 11 is just for the segfault at the end. Other programs that segfault also result in a similar error trace with signal 11.)
Is this a known issue? Any help is appreciated.
Thanks.